ATIS 0100003-2004 User Plane Priority Levels for IP Networks and Services.pdf

《ATIS 0100003-2004 User Plane Priority Levels for IP Networks and Services.pdf》由会员分享，可在线阅读，更多相关《ATIS 0100003-2004 User Plane Priority Levels for IP Networks and Services.pdf（12页珍藏版）》请在麦多课文档分享上搜索。

1、 ATIS-0100003 User Plane Priority Levels for IP Networks and Services TECHNICAL REPORT The Alliance for Telecommunication Industry Solutions (ATIS) is a technical planning and standards development organization that is committed to rapidly developing and promoting technical and operations standards

2、for the communications and related information technologies industry worldwide using a pragmatic, flexible and open approach. Over 1,100 participants from more than 350 communications companies are active in ATIS 23 industry committees and its Incubator Solutions Program. ATIS-0100003, User Plane Pr

3、iority Levels for IP Networks and Services Is an ATIS Standard developed by the Network Reliability and Security Working Group under the ATIS Network Performance, Reliability, and Quality of Service Committee (PRQC). Published by Alliance for Telecommunications Industry Solutions 1200 G Street, NW,

4、Suite 500 Washington, DC 20005 Copyright 2006 by Alliance for Telecommunications Industry Solutions All rights reserved. No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written permission of the publisher. For information c

5、ontact ATIS at 202.628.6380. ATIS is online at . Printed in the United States of America. ATIS-0100003 Technical Report on User Plane Priority Levels for IP Networks and Services Secretariat Alliance for Telecommunications Industry Solutions Approved November 2004 Abstract This Technical Report (TR)

6、 was developed as a formal response to a request from the ATIS sub-committee PTSC-SAC for guidance on user plane priority levels in IP networks. This TR proposes three levels of connection admission control priority for the user plane communications traffic in IP networks. It also proposes that all

7、emergency communications (e.g., ETS and E911) be given the highest priority for call/session setup. ATIS-0100003 ii FOREWORD This Technical Report (TR) provides a formal response to a request from ATIS sub-committee PTSC-SAC (formerly T1S1.7) for guidance on the number of user plane priority levels

8、in IP networks. This TR is intended for providers of IP-based communications networks and services, communications equipment suppliers, and government agencies responsible for addressing emergency situations. The Alliance for Telecommunication Industry Solutions (ATIS) serves the public through impr

9、oved understanding between carriers, customers, and manufacturers. The Network Performance, Reliability, and Quality of Service Committee (PRQC) formerly T1A1 develops and recommends standards, requirements, and technical reports related to the performance, reliability, and associated security aspec

10、ts of communications networks, as well as the processing of voice, audio, data, image, and video signals, and their multimedia integration. PRQC also develops and recommends positions on, and foster consistency with, standards and related subjects under consideration in other North American and inte

11、rnational standards bodies. Suggestions for improvement of this document are welcome. They should be sent to the Alliance for Telecommunications Industry Solutions, PRQC Secretariat, 1200 G Street N.W., Suite 500, Washington, DC 20005. The Network Reliability and Security Working Group on Network Pe

12、rformance, Reliability, and Quality of Service was responsible for the development of this document, and had the following officers and participants: O. Avellaneda, Chair S. Makris, Vice Chair F. Kaudel, Chief Editor P. Tarapore, A. Nguyen, and A. Webster; Technical Editors C. Underkoffler, ATIS Chi

13、ef Editor Active Participants: J. Ash O. Avellaneda C. Bailey J. Bennett M. Dolly C. Dvorak P. Kimbrough J. Lankford S. Makris A. McCain A. Nguyen R. Paterson S. Sayers N. Seitz P. Tarapore A. Webster R. Wohlert ATIS-0100003 iii TABLE OF CONTENTS FOREWORD .II TABLE OF CONTENTS III 1 PURPOSE 1 2 SCOP

14、E 1 3 APPLICATION . 2 4 RELATED WORK 3 5 CAC PRIORITY PRINCIPLES. 3 6 RECOMMENDATION FOR CAC PRIORITY LEVELS. 4 7 FLEXIBILITY. 5 8 CONCLUSION 5 9 DEFINITIONS. 5 10 ABBREVIATIONS AND ACRONYMS 6 11 REFERENCES 6 ATIS-0100003 Technical Report on User Plane Priority Levels for IP Networks and Services 1

15、1 PURPOSE The ATIS sub-committee PTSC-SAC (formerly T1S1.7) submitted a formal request to the ATIS Network Performance, Reliability, and Quality of Service Committee (PRQC) 1 formerly known as T1A1 for guidance on the number of priority levels for IP services. The basis for this request stems from a

16、 need to develop priority-based signaling extensions in appropriate protocols (e.g., Session Initiation Protocol SIP) such that critical services such as Emergency Telecommunications Services (ETS) 2and E911 are preferentially recognized for call/session setup in IP networks. This document is the fo

17、rmal response from PRQC to the PTSC-SAC. It recommends three priority class levels for IP services in the user plane. It also recommends that the highest priority level be reserved for emergency services such as ETS and E911. 2 SCOPE From the perspective of the network, it is expected that future IP

18、 networks will be truly “converged.” That is, all forms of communications traffic will be handled by such networks control plane traffic (e.g., routing and signaling messages), emergency services, real-time voice and video services, data services, Virtual Private Network (VPN) services, as well as t

19、raditional “Best Effort” traffic. In such an environment, it is important to assign priority classifications and establish rules for capacity reservation and admission such that critical services (e.g., control plane traffic and emergency services) are recognized and accepted for call/session setup

20、and completion (or simply carried in the case of non-session oriented traffic) over other services in case of network overloads or failures. As service flows can be expected to traverse multiple network domains, priority classification is an important step in the development of the necessary signali

21、ng protocol extensions as well as the mechanisms for enabling preferential treatment of critical services. The scope of this recommendation is limited to the determination of user (or media/bearer) plane priority class levels for communications over IP networks. The underlying support for this recom

22、mendation is based on the potential impact on IP services due to failure or congestion conditions. Specifically, the recommendation seeks to cast a broad view on priority classification, namely; what should the proper number of classes be such that critical services are given the highest probability

23、 of successful call/session setup and completion under congested conditions. For example, it is recognized that a class of “emergency services” can comprise Federal ETS as well as local E911 calls and that this class of traffic requires priority treatment in case of emergency. The goal of this docum

24、ent is to distinguish this class of traffic from other less critical classes of traffic. However, this document does not seek to “fine tune” the treatment of different traffic types within a broad priority class or level. Thus, the ability to distinguish between service types within any given priori

25、ty class (e.g., distinguish between ETS and E911 services in the emergency service class) is beyond the scope of this document. ATIS-0100003 2 As stated above, it is recognized that control plane traffic is critical for ensuring smooth network operations as well as inter-domain signaling interaction

26、s. However, control plane traffic priority determination and its relative criticality compared to user plane traffic (e.g., highest available priority for control plane traffic over all user plane traffic) is not considered at this stage for the following reasons: The initial request from the Protoc

27、ol Inter-working Committee was driven by a need to understand the priority levels available/supported by the user plane traffic. Call control messages in protocols such as SIP can then be mapped to the recommended priority levels. These levels can also assist in follow-on questions such as mapping t

28、he recommended priority levels to priorities within the packet queuing algorithm at the network border element to the IP backbone 3. The composition of control plane traffic can vary depending on the type of IP networking capabilities ranging from simple Best Effort services only to more sophisticat

29、ed MPLS-based services such as VPNs. Thus intra-domain control plane traffic can comprise, for example, OSPF messages, as well as protocol messages in support of Multi-Protocol Label Switching (MPLS) features. In addition, control plane traffic can also include inter-domain messages representing BGP

30、 and signaling protocol messages (e.g., SIP messages). The exact mix and volume of intra and inter-domain control plane traffic as a proportion of total network traffic is somewhat uncertain and a matter for further study. The question of the relative importance of the various forms of control plane

31、 traffic compared to customer-based bearer plane traffic has yet to be addressed. For example, it may be essential to reach agreements on the relative priority of inter-domain control plane traffic. However, service carriers may chose to treat intra-domain control plane traffic according to their in

32、dividual network needs. Control plane traffic priority questions are very important and they need to be addressed in future efforts. It is hoped that addressing user plane traffic priority questions as a first step, can eventually lead towards acceptable agreements on control plane traffic questions

33、. 3 APPLICATION The priority level classification is based on the following premise: under reduced bandwidth conditions, the critical issue for an IP network is the ability to recognize and admit higher priority traffic flows into the network. This can be referred to as a traditional form of Connect

34、ion Admission Control (CAC) priority classification. The priority level recommendations proposed in this document strictly relate to the relative importance of traffic classes from this perspective; they do not reflect implementation specific priority definitions. For example, there are mechanisms u

35、tilizing Multi-Protocol Label Switching - Traffic Engineering (MPLS-TE) that define specific priorities such as Label Switched Path (LSP) setup priority, holding priority, and preemption priority 4. Such mechanism-specific priority definitions do not apply to the recommendations in this document. AT

36、IS-0100003 3 4 RELATED WORK A significant amount of work on ETS requirements is ongoing in various standards bodies. A detailed list of such efforts can be found in the ATIS/PRQC Technical Report T1.TR.79-2003, Overview of Standards in Support of Emergency Telecommunications Service (ETS) 2. An ATIS

37、 Technical Report originated by the PRQC committee documents the need for traffic prioritization from the perspective of emergency services 5. ANSI standard T1.202-2004 developed by the ATIS Telecom Management and Operations Committee provides network management guidelines and recommendations under

38、disaster conditions 6. In the ITU-T, Recommendation E.361 7has progressed work on the definition of reliability and priority parameters for QoS service classes. This Recommendation also provides useful insights on the priority signaling across multiple networks. ITU-T Recommendation Y.1541 8provides

39、 a classification of IP communications services from the perspective of performance requirements. ITU-T Recommendation Y.1291 9presents a discussion on priority levels for CAC and service restoration functions in packet networks. In the IETF Next Steps in Signaling (NSIS) Working Group, work is ongo

40、ing to define Quality of Service (QoS) modeling parameters in IP networks. Initial efforts include the use of priority parameters 10. The goal of this effort is to eventually embrace QoS and priority parameters that apply to specific mechanisms such that these values can be signaled throughout an IP

41、 network. Also in the IETF, the label distribution for Traffic Engineering and QoS (and hence priority) can be accomplished via the Resource Reservation Protocol Traffic Engineering (RSVP-TE) 11. This protocol permits the creation of explicitly routed LSPs and provides fast rerouting, traffic and Qo

42、S specification, preemption, and other capabilities. 5 CAC PRIORITY PRINCIPLES CAC policies provide the means to preferentially admit critical traffic flows into an IP network. For example, in an MPLS network, a higher priority service can be admitted by setting up an appropriate LSP in preference o

43、ver a lower priority service by reserving the last available, minimum-level of bandwidth (called the “reserved bandwidth“) for the higher priority service LSP set up 5. The higher priority service only uses the reserved bandwidth for LSP setup when that is all the bandwidth left. In emergency condit

44、ions, when service network capacities are likely to be reduced, effective CAC mechanisms that recognize agreed upon priority services such as emergency communications, are critical to the successful setup and transmission of such services. The following principles can be used for guidance in order t

45、o establish a set of priority levels for CAC functions in IP networks: CAC Priority Lower Bound/Diversity of IP Services: The evolution of IP networks is driven by the idea of convergence the ability to transmit all types of communications traffic over IP backbones. Thus, service providers are incre

46、asingly planning the use of “converged” IP networks to carry real-time services such as Voice over IP (VoIP) as well as video, private data traffic (exemplified by VPN traffic), emergency traffic (VoIP, and in the future, data and video), in addition to todays “traditional” Best Effort services such

47、 as e-mail and web browsing. This suggests that simply categorizing bearer plane traffic as “emergency” and “other” may not be sufficient. Under such a two-level scheme, CAC policies may be likely to reject VPN and real-time VoIP traffic just as equally as Best Effort traffic in order to preferentia

48、lly admit higher ATIS-0100003 4 priority traffic (e.g., ETS calls) under emergency conditions. This suggests that while two levels could serve as a lower bound for the number of bearer plane traffic CAC priorities, the actual number of levels should be higher. The goal is to ensure that, as far as p

49、ossible, the maximum rejection for incoming traffic flows is borne by the Best Effort traffic class. CAC Priority Upper Bound: The advent of IP networking involved a single “Best Effort” class of service for simplicity. Subsequently, the ability of newer MPLS-based mechanisms can provide ways to distinguish different service types; however, these mechanisms do not suggest an arbitrarily large number of priority levels. For example, MPLS-based LSPs are assigned an EXP (experimental) bit value that may be used as a QoS indic