ATIS 1000020-2007 ETS Packet Priority for IP NNI Interfaces - Requirements for a Separate Expedited Forwarding Mechanism.pdf

《ATIS 1000020-2007 ETS Packet Priority for IP NNI Interfaces - Requirements for a Separate Expedited Forwarding Mechanism.pdf》由会员分享，可在线阅读，更多相关《ATIS 1000020-2007 ETS Packet Priority for IP NNI Interfaces - Requirements for a Separate Expedited Forwarding Mechanism.pdf（9页珍藏版）》请在麦多课文档分享上搜索。

1、 ATIS-1000020 ETS PACKET PRIORITY FOR IP NNI INTERFACES REQUIREMENTS FOR A SEPARATE EXPEDITED FORWARDING MECHANISM TECHNICAL REPORT The Alliance for Telecommunication Industry Solutions (ATIS) is a technical planning and standards development organization that is committed to rapidly developing and

2、promoting technical and operations standards for the communications and related information technologies industry worldwide using a pragmatic, flexible and open approach. Over 1,100 participants from over 300 communications companies are active in ATIS 22 industry committees and its Incubator Soluti

3、ons Program. Notice of Disclaimer & Limitation of Liability The information provided in this document is directed solely to professionals who have the appropriate degree of experience to understand and interpret its contents in accordance with generally accepted engineering or other professional sta

4、ndards and applicable regulations. No recommendation as to products or vendors is made or should be implied. NO REPRESENTATION OR WARRANTY IS MADE THAT THE INFORMATION IS TECHNICALLY ACCURATE OR SUFFICIENT OR CONFORMS TO ANY STATUTE, GOVERNMENTAL RULE OR REGULATION, AND FURTHER, NO REPRESENTATION OR

5、 WARRANTY IS MADE OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR AGAINST INFRINGEMENT OF INTELLECTUAL PROPERTY RIGHTS. ATIS SHALL NOT BE LIABLE, BEYOND THE AMOUNT OF ANY SUM RECEIVED IN PAYMENT BY ATIS FOR THIS DOCUMENT, WITH RESPECT TO ANY CLAIM, AND IN NO EVENT SHALL ATIS BE LIABLE FO

6、R LOST PROFITS OR OTHER INCIDENTAL OR CONSEQUENTIAL DAMAGES. ATIS EXPRESSLY ADVISES ANY AND ALL USE OF OR RELIANCE UPON THIS INFORMATION PROVIDED IN THIS DOCUMENT IS AT THE RISK OF THE USER. NOTE - The users attention is called to the possibility that compliance with this standard may require use of

7、 an invention covered by patent rights. By publication of this standard, no position is taken with respect to whether use of an invention covered by patent rights will be required, and if any such use is required no position is taken regarding the validity of this claim or any patent rights in conne

8、ction therewith. ATIS-1000020, ETS Packet Priority for IP NNI Interfaces Requirements for a Separate Expedited Forwarding Mechanism Is an ATIS Standard developed by the Signalling, Architecture, and Control (SAC) Subcommittee under the ATIS Packet Technologies and Systems Committee (PTSC). Published

9、 by Alliance for Telecommunications Industry Solutions 1200 G Street, NW, Suite 500 Washington, DC 20005 Copyright 2008 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

10、, without the prior written permission of the publisher. For information contact ATIS at 202.628.6380. ATIS is online at . Printed in the United States of America. ATIS-1000020 ATIS Standard on ETS PACKET PRIORITY FOR IP NNI INTERFACES REQUIREMENTS FOR A SEPARATE EXPEDITED FORWARDING MECHANISM Secre

11、tariat Alliance for Telecommunications Industry Solutions Approved October 2007 Abstract This Technical Report (TR) provides the requirements for a separate Expedited Forwarding (EF) mechanism that can recognize a class of traffic for preferential treatment via a unique DiffServ Code Point (DSCP). T

12、his class of traffic includes Emergency Telecommunications Service (ETS) Voice over IP (VoIP) calls/sessions with the requirement of a pre-determined quantity of reserved bandwidth for ETS service. ATIS-1000020 ii FOREWORD The Alliance for Telecommunication Industry Solutions (ATIS) serves the publi

13、c through improved understanding between carriers, customers, and manufacturers. The Packet Technologies and Systems Committee (PTSC) formerly T1S1 develops and recommends standards and technical reports related to services, architectures, and signaling, in addition to related subjects under conside

14、ration in other North American and international standards bodies. PTSC coordinates and develops standards and technical reports relevant to telecommunications networks in the U.S., reviews and prepares contributions on such matters for submission to U.S. ITU-T and U.S. ITU-R Study Groups or other s

15、tandards organizations, and reviews for acceptability or per contra the positions of other countries in related standards development and takes or recommends appropriate actions. Suggestions for improvement of this document are welcome. They should be sent to the Alliance for Telecommunications Indu

16、stry Solutions, PTSC Secretariat, 1200 G Street NW, Suite 500, Washington, DC 20005. At the time it approved this document, PTSC, which is responsible for the development of this Technical Report (TR), had the following members: B. Hall, PTSC Chair J. Zebarth, PTSC Vice-Chair C. Underkoffler, ATIS C

17、hief Editor M. Dolly, PTSC Technical Editor P. Tarapore, PTSC Technical Editor Organization Represented Name of Representative AcmePacket Kevin Klett Alcatel-Lucent Stuart Goldman AT&T Bob Hall George Stanek (Alt) Avici Systems Esmeralda Swartz Cingular Wireless LLC Don Zelmer Marc Grant (Alt) Cisco

18、 Systems Rajiv Kapoor Mike Hammer (Alt) Consultant Bob Hall Department of Defense Chris Fitzgerald Ryan Kuseski (Alt) Embarq Corporation John Heinz Bill Wiley (Alt) Ericsson Incorporated Susana Sabater-Maroto Stephen Hayes (Alt) ETI Connect Peter Dyrholm David Cooke(Alt) ETRI Shin Gak-Kang Wook Hyun

19、 (Alt) FBI ESTS Marybeth Paglino Edward Ignacio (Alt) Hewlett-Packard Steve Mills Intel Corporation Walt Brown Intelsat Mark Neibert Microsoft Corporation Wendy Fong Motorola Inc. Syed Husain Organization Represented Name of Representative National Communications Systems Nicholas Andre An Nguyen (Al

20、t) NEC Corporation of America John McDonough Milorad Cvijetic (Alt) NeuStar Peggy Rehn Tom McGarry (Alt) Nokia Telecommunications Inc. Joyabrata Mukherjee Ed Ehrlich (Alt) Nortel Joseph Zebarth PSEP Canada Sim Simanis Sean Pope (Alt) Qwest Steve Showell Andrew White (Alt) Siemens Communications, Inc

21、. Ron Franks David E. Fransico Sprint Nextel Mark L. Jones SS8 Networks Cemal Dikmen Scott Coleman (Alt) Telcordia Technologies Wesley Downum Cliff Halevi (Alt) Tellabs Operations William A. Walker Tridea Works Selvan Rengasami Ken Coon (Alt) VeriSign, Inc. Anthony M. Rutkowski Verizon Communication

22、s Thomas Helmes Dave Morris The Signalling, Architecture, and Control (SAC) Subcommittee was responsible for the development of this document. ATIS-1000020 ii TABLE OF CONTENTS 1 SCOPE.1 1.1 BACKGROUND.1 2 REFERENCES .1 3 DEFINITIONS2 4 ABBREVIATIONS & ACRONYMS 2 5 ASSUMPTIONS FOR ETS SERVICE .2 6 R

23、EQUIREMENTS FOR ETS VOIP SERVICE 3 7 CONSTRAINT OF A SINGLE EF MECHANISM FOR VOIP ETS SERVICE3 8 ETS VOIP SERVICES REQUIREMENTS FOR A NEW EF CODE POINT.4 ATIS STANDARD ATIS-1000020 ATIS Standard on ETS Packet Priority for IP NNI Interfaces Requirements for a Separate Expedited Forwarding Mechanism 1

24、 SCOPE This Technical Report (TR) provides the requirements for a separate Expedited Forwarding (EF) mechanism that can recognize a class of traffic for preferential treatment via a unique DiffServ Code Point (DSCP). This class of traffic includes Emergency Telecommunications Service (ETS) Voice ove

25、r IP (VoIP) calls/sessions with the requirement of a pre-determined quantity of reserved bandwidth for ETS service. 1.1 Background ATIS PTSC has completed a TR 1that recommends the use of a predetermined Local/Experimental DiffServ Code Point (DSCP) for ETS VoIP traffic particularly at Network-Netwo

26、rk Interfaces (NNI). The justification for this recommendation is based on current limitations of the Expedited Forwarding (EF) Per Hop Behavior (PHB) 2in Differentiated Services 3and on the high admission control priority requirements for ETS in IP networks 4, 5. In the IETF, work has commenced on

27、the development of a separate EF code point to be assigned by IANA for Capacity-Admitted Traffic6. An operator can treat the ETS class of service requiring preferential treatment as a type of Capacity-Admitted traffic that uses that separate EF code point. Recognizing the limitations of a Local/Expe

28、rimental DSCP, this TR provides requirements that could be used by the IETF to continue its standardization work. 2 REFERENCES 1 ATIS-1000011, ETS Packet Priority for NNI Interfaces Use of Existing DiffServ Per Hop Behaviors.12 IETF RFC 3246, An Expedited PHB (Per Hop Behavior), March 2002.23 IETF R

29、FC 2475, An Architecture for Differentiated Services, December 1998.24 ATIS-0100003, User Plane Priority Levels for IP Networks and Services.15 ATIS-1000005, Service Description of ETS. 6 “An EF DSCP for Capacity-Admitted Traffic”, F. Baker, J. Polk, and M. Dolly, IETF I-D, December 2006 (work in pr

30、ogress). 1This document is available from the Alliance for Telecommunications Industry Solutions (ATIS), 1200 G Street N.W., Suite 500, Washington, DC 20005. 2This document is available from the Internet Engineering Task Force (IETF). 1 ATIS-1000020 7 IETF RFC 4412, Communications Resource Priority

31、for the Session Initiation Protocol (SIP), February 2006. 8 ITU-T Recommendation Y.1541, Network Performance Objectives for IP-Based Services, June 2006.33 DEFINITIONS None identified in this document. 4 ABBREVIATIONS & ACRONYMS AF Assured Forwarding BE Best Effort CAC Call Admission Control IETF In

32、ternet Engineering Task Force DiffServ Differentiated Services DSCP DiffServ Code Point EF Expedited Forwarding ETS Emergency Telecommunications Service GETS Government Emergency Telecommunications Service NNI Network To Network Interface PHB Per Hop Behavior RFC Request For Comments SIP Session Ini

33、tiation Protocol UNI User To Network Interface WPS Wireless Priority Service 5 ASSUMPTIONS FOR ETS SERVICE The specific assumptions related to ETS service over IP networks used within this document are as follows: VoIP ETS service over IP networks is expected to be ubiquitous over public domain serv

34、ice providers as specified for ETS service over IP networks 5. This is analogous to the Government Emergency Telecommunications Service (GETS) service model in the PSTN network. The total volume of VoIP ETS traffic is expected to be small (based on historical data) when compared to the total IP traf

35、fic transported by a public domain service provider. However, based on past experience, during emergency conditions, this small volume of ETS traffic has to compete with a significant spike in non-ETS voice traffic for a depleted set of network resources depending on the type of local/regional/natio

36、nal emergency. ETS service is considered to be High Priority from a perspective of admission into IP-based networks 4. All ETS calls are expected to be admitted into the network with stringent QoS 3This document is available from the International Telecommunications Union. 2 ATIS-1000020 requirement

37、s as specified by Y.1541 Class 1 performance up to a specified upper limit based on service level agreements. Preemption of non-ETS VoIP calls is prohibited in the public domain for the purpose of admitting High Priority ETS calls into the network and this practice will not change on a going forward

38、 basis. VoIP ETS traffic makes use of two Session Initiation Protocol (SIP) Resource Priority Header (RPH) 7“namespaces”, ets and wps: o ETS Namespace: ETS calls over an IP network are grouped into this namespace. All ETS calls with this SIP RPH header are given High Priority in the transport layer.

39、 o WPS (Wireless Priority Service) Namespace: An emergency call may originate over a wireless technology (e.g., 3GPP) access network with a wps namespace assignment, in addition to an ets namespace, and be handed off to a wireline IP network for further transport. The wps value is relayed by the IP

40、network to facilitate priority treatment at the wireless egress network. However, the call is treated as an ets namespace call by the IP network. o All traffic types characterized by other “namespaces” defined in the SIP RPH header apply to “private” networks, and these traffic types and their suppo

41、rting private networks are beyond the scope of this document. 6 REQUIREMENTS FOR ETS VOIP SERVICE The following requirements must be met for the purpose of preferentially admitting High Priority ETS VoIP service: ETS calls in IP networks must be assigned “High” priority from the perspective of admis

42、sion/resource allocation as described in ATIS documents 4. The “High” priority for admission/resource allocation must be maintained across NNI interfaces. Non-ETS VoIP calls must be assigned an admission/resource allocation priority that is less than ETS. Preemption of calls in progress is not accep

43、table as a solution. QoS for ETS VoIP calls are expected to conform to performance requirements as specified by ITU-T Recommendation Y.1541 Class 1 8. This class of service preserves the strict jitter and packet loss requirements while permitting longer delays for international emergency calls. The

44、bottom line during emergency conditions is that ETS VoIP packets should not be dropped, in order to preserve the integrity of these critical calls. 7 CONSTRAINT OF A SINGLE EF MECHANISM FOR VOIP ETS SERVICE VoIP ETS traffic is expected to represent a very small proportion ( 60%). The issue at hand i

45、s how to ensure that critical High Priority ETS calls can successfully complete under emergency conditions involving potentially significant depletion of network resources. In a public domain IP network, it is expected that (under emergency conditions) bottlenecks will occur at the network boundary

46、interfaces user to network facing interfaces (UNI) or network-network interfaces (NNI). The core backbones are typically engineered with large amounts of spare 3 ATIS-1000020 bandwidth/resources. However, depending on the severity of the emergency, even core interfaces may experience diminished reso

47、urces and bottlenecks. Thus, a regional or a national emergency may create significant loss of network resources, and the impact is typically felt at the UNI and NNI interfaces of the network and possibly even at core interfaces. At the same time, traffic volumes during emergency conditions have bee

48、n known to increase significantly with the bulk of the increase coming from residential voice calls as the affected population seeks help or tries to establish the safety of family and friends during these conditions. To summarize, emergency conditions result in diametrically opposite outcomes for a

49、 network depleted network resources particularly at UNI and NNI interfaces along with a significant surge of incoming real-time voice traffic. The inability of the single EF code point to distinguish ETS calls from other calls comes into play during emergency conditions. In the absence of strict Capacity Admission Control for non-ETS VoIP calls, the likely state of the network during such conditions may overwhelm the potentially depleted resources for the existing EF code point, such