1、 International Telecommunication Union ITU-T Series E.800TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU Supplement 8(11/2009) SERIES E: OVERALL NETWORK OPERATION, TELEPHONE SERVICE, SERVICE OPERATION AND HUMAN FACTORS Guidelines for inter-provider quality of service ITU-T E.800-series Recommendatio
2、ns Supplement 8 ITU-T E-SERIES RECOMMENDATIONS OVERALL NETWORK OPERATION, TELEPHONE SERVICE, SERVICE OPERATION AND HUMAN FACTORS INTERNATIONAL OPERATION Definitions E.100E.103 General provisions concerning Administrations E.104E.119 General provisions concerning users E.120E.139 Operation of interna
3、tional telephone services E.140E.159 Numbering plan of the international telephone service E.160E.169 International routing plan E.170E.179 Tones in national signalling systems E.180E.189 Numbering plan of the international telephone service E.190E.199 Maritime mobile service and public land mobile
4、service E.200E.229 OPERATIONAL PROVISIONS RELATING TO CHARGING AND ACCOUNTING IN THE INTERNATIONAL TELEPHONE SERVICE Charging in the international telephone service E.230E.249 Measuring and recording call durations for accounting purposes E.260E.269 UTILIZATION OF THE INTERNATIONAL TELEPHONE NETWORK
5、 FOR NON-TELEPHONY APPLICATIONS General E.300E.319 Phototelegraphy E.320E.329 ISDN PROVISIONS CONCERNING USERS E.330E.349 INTERNATIONAL ROUTING PLAN E.350E.399 NETWORK MANAGEMENT International service statistics E.400E.404 International network management E.405E.419 Checking the quality of the inter
6、national telephone service E.420E.489 TRAFFIC ENGINEERING Measurement and recording of traffic E.490E.505 Forecasting of traffic E.506E.509 Determination of the number of circuits in manual operation E.510E.519 Determination of the number of circuits in automatic and semi-automatic operation E.520E.
7、539 Grade of service E.540E.599 Definitions E.600E.649 Traffic engineering for IP-networks E.650E.699 ISDN traffic engineering E.700E.749 Mobile network traffic engineering E.750E.799 QUALITY OF TELECOMMUNICATION SERVICES: CONCEPTS, MODELS, OBJECTIVES AND DEPENDABILITY PLANNING Terms and definitions
8、 related to the quality of telecommunication services E.800E.809Models for telecommunication services E.810E.844 Objectives for quality of service and related concepts of telecommunication services E.845E.859 Use of quality of service objectives for planning of telecommunication networks E.860E.879
9、Field data collection and evaluation on the performance of equipment, networks and services E.880E.899 OTHER E.900E.999 INTERNATIONAL OPERATION Numbering plan of the international telephone service E.1100E.1199 For further details, please refer to the list of ITU-T Recommendations. E.800-series Supp
10、lement 8 (11/2009) i Supplement 8 to ITU-T E.800-series Recommendations Guidelines for inter-provider quality of service Summary Supplement 8 to the ITU-T E.800-series of Recommendations was originally prepared as a white paper by the Interconnection Working Group of the Communications Futures Progr
11、am (CFP) of the Massachusetts Institute of Technology (MIT). It presents an approach to the deployment of inter-provider quality of service (QoS) to enable further consideration of the topic. This Supplement discusses key issues that service providers need to agree upon if inter-provider QoS is to b
12、e readily deployable. Source Supplement 8 to ITU-T E.800-series Recommendations was agreed on 12 November 2009 by ITU-T Study Group 12 (2009-2012). ii E.800-series Supplement 8 (11/2009) FOREWORD The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of
13、 telecommunications, information and communication technologies (ICTs). The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing t
14、elecommunications on a worldwide basis. The World Telecommunication Standardization Assembly (WTSA), which meets every four years, establishes the topics for study by the ITU-T study groups which, in turn, produce Recommendations on these topics. The approval of ITU-T Recommendations is covered by t
15、he procedure laid down in WTSA Resolution 1. In some areas of information technology which fall within ITU-Ts purview, the necessary standards are prepared on a collaborative basis with ISO and IEC. NOTE In this publication, the expression “Administration“ is used for conciseness to indicate both a
16、telecommunication administration and a recognized operating agency. Compliance with this publication is voluntary. However, the publication may contain certain mandatory provisions (to ensure e.g., interoperability or applicability) and compliance with the publication is achieved when all of these m
17、andatory provisions are met. The words “shall“ or some other obligatory language such as “must“ and the negative equivalents are used to express requirements. The use of such words does not suggest that compliance with the publication is required of any party. INTELLECTUAL PROPERTY RIGHTS ITU draws
18、attention to the possibility that the practice or implementation of this publication may involve the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence, validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or othe
19、rs outside of the publication development process. As of the date of approval of this publication, ITU had not received notice of intellectual property, protected by patents, which may be required to implement this publication. However, implementers are cautioned that this may not represent the late
20、st information and are therefore strongly urged to consult the TSB patent database at http:/www.itu.int/ITU-T/ipr/. ITU 2010 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of ITU. E.800-series Supplement 8 (11/2009) i
21、ii CONTENTS Page 1 Introduction 2 1.1 Scope 2 1.2 Relationship to standards 3 2 Reference model and terminology 3 2.1 Definitions 3 2.2 Reference approach 5 2.3 Basic reference case . 5 2.4 Inter-provider reference case 6 2.5 DSCP marking 7 2.6 Routing . 8 2.7 Measurement and management 8 3 Service
22、class . 9 3.1 Network service classes 9 3.2 Customer to provider interface (CPI) behaviour 10 3.3 Network-to-network interface (NNI) behaviour 11 3.4 Definitions of metrics . 12 3.5 Class 0 service definition 14 3.6 Impairment budgets 14 3.7 Proposed allocation approach . 16 3.8 Assessment reference
23、 model 17 3.9 Budget allocation 18 3.10 Admission management . 21 4 QoS measurement . 22 4.1 QoS measurement requirements . 22 4.2 QoS measurement methodologies 24 4.3 QoS measurement protocols . 24 4.4 Measurement considerations for VPN services 25 4.5 Recommended measurement approach 25 4.6 Perfor
24、mance measurement metrics . 26 4.7 Reporting of measurement results 27 4.8 QoS measurement security considerations . 28 5 Routing . 28 5.1 Current BGP capabilities 29 5.2 BGP considerations 29 5.3 Routing recommendation . 30 6 Securing QoS 30 6.1 Motivation 30 6.2 Areas which need to be secure . 30
25、iv E.800-series Supplement 8 (11/2009) Page 6.3 Provisioning security 30 6.4 Service security 33 6.5 Security guidelines . 33 7 Operational issues . 34 7.1 Fault 35 7.2 Configuration and maintenance 35 7.3 Accounting . 37 7.4 Performance 37 8 References. 38 Appendix I Examples of the application of
26、budget allocations 40 I.1 Case 1: Three core providers 40 I.2 Case 2: Transcontinental service, five core providers 40 E.800-series Supplement 8 (11/2009) 1 Supplement 8 to ITU-T E.800-series Recommendations Guidelines for inter-provider quality of service Executive summary This Supplement presents
27、an approach to the deployment of inter-provider quality of service (QoS). This Supplement begins from the observation that QoS, based on the differentiated services architecture defined in IETF RFC 2475 is now widely deployed within the networks of single providers. This is especially the case for p
28、roviders of network-based VPNs (see, for example IETF RFC 2547, and IETF RFC 4364). Some providers are now beginning to interconnect with each other via “QoS-enabled peering“ in an attempt to offer QoS that spans the networks of multiple providers. However, in the absence of appropriate standards an
29、d established procedures for management, trouble-shooting, monitoring, etc., such interconnections are likely to be challenging and labour-intensive. This Supplement discusses key issues that service providers need to agree upon if inter-provider QoS is to be readily deployable. NOTE As this Supplem
30、ent is a vehicle for sharing research topics under consideration, there may be some conflicts between this Supplement and existing ITU-T Recommendations. In such conflicts, the reader is reminded that Supplements are only informative and are therefore not considered to be an integral part of any Rec
31、ommendation; they do not imply any agreement on the part of the ITU-T. This Supplement: Takes the approach of describing the simplest multi-class, multi-provider network scenario (i.e., a single end-to-end low-loss and low-latency class (Class 0) which is offered as a service to customers, in additi
32、on to the best-effort class). This does not limit the same approach being applied to multi-provider end-to-end services with IP QoS classes other than the two classes described. Assumes that most regional (intra-continental) end-to-end connections will span no more than 3 core provider networks. Ide
33、ntifies “common practices“ that could ease the deployment of inter-provider QoS if adopted by a critical mass of providers. While there is continued debate about how many service classes need to be supported across multiple providers, it is widely agreed that some moderate number of classes should b
34、e commonly supported and consistently defined among providers. This Supplement uses the two-class scenario as it is the simplest multi-class service offering. This is done as a way of exposing the issues that must be addressed. The additional service class that is defined is intended to be suitable
35、for real-time voice applications, and is intended to be appropriate for use both in a provider-provisioned VPN context and in public networks. It is noted that, in many cases, providers may internally make use of an additional class of service that is restricted to network control traffic (such as r
36、outing protocol traffic and network management traffic). The key issues that are addressed in this Supplement are: Consistent definitions of metrics: To support QoS meaningfully across multiple providers, it is essential that metrics such as delay, delay variation and loss are defined consistently.
37、Service class definition: The “Class 0“ service class is defined in terms of what the customer must do to receive the service (e.g., mark packets with a certain DSCP, conform to a certain token bucket) and what the provider in turn commits to deliver (e.g., statistical upper bounds on loss and delay
38、). Although this Supplement only outlines detailed criteria for a single class of service beyond best effort, its goal is to remain flexible so that additional classes of service may be added. Furthermore, any individual service provider is free to offer additional service classes beyond those defin
39、ed here. 2 E.800-series Supplement 8 (11/2009) Measurement, monitoring and reporting: Because of the multiple parties involved in the delivery of QoS, it is necessary to have defined methods for measurement of QoS, ways to monitor the performance of different network segments, and ways to report per
40、formance consistently among providers. Such methods are defined in this Supplement. Routing: It may be necessary to route QoS-sensitive traffic to different providers or along different routes than those followed by best-effort traffic. Routing considerations are discussed. Provider responsibilities
41、: There may need to be some agreed-upon responsibilities and “common practices“ to which providers should agree. A set of such practices is proposed that simplifies deployment of inter-provider QoS among a large set of providers. 1 Introduction Quality of service (QoS) technologies based on the diff
42、erentiated services architecture outlined in IETF RFC 2475 is now widely deployed within the networks of many service providers. This is especially the case for providers of network-based VPNs (see, for example IETF RFC 2547, and IETF RFC 4364). Some providers are now beginning to interconnect with
43、each other via “QoS-enabled peering“ in an attempt to offer QoS that spans the networks of multiple providers. However, in the absence of appropriate standards and established procedures for management, trouble-shooting, monitoring, etc., such interconnections have proven to be challenging and labou
44、r-intensive. This Supplement seeks to identify the key issues that service providers need to agree upon if inter-provider QoS is to be readily deployable. 1.1 Scope It is the intent of this Supplement to discuss guidelines that are applicable to the interconnection of VPNs spanning multiple service
45、providers. Because QoS deployment is much better established in private networks than in public networks, VPN provider interconnection is the primary focus, but the intent is to outline solutions that may also be applicable to public network service interconnection as well. Specific guidelines for p
46、ublic network service interconnection are for further study. This Supplement is primarily concerned with the network support for two service classes across multiple providers networks. These two classes being: A service class suitable for latency and loss insensitive data (Class 5). An additional se
47、rvice class, considered more suitable for the transport of conversational voice over IP (VoIP) and other latency and loss-sensitive applications (Class 0). A key distinguishing characteristic of private network services, compared to public network services, for services guaranteeing low packet loss
48、and delay, is that the service provider(s) may not need to implement any means of avoiding congestion occurring for traffic in this class. This is discussed further in clause 3.10. Within the VPN context, it is likely that many VPN providers will deliver a service based on IETF RFC 4364 (BGP/MPLS VP
49、Ns, formerly known as 2547 VPNs1). This Supplement will not restrict itself to BGP/MPLS VPNs any IP VPN service should be supported but the specific QoS issues of interconnecting providers of BGP/MPLS VPNs are addressed, including the MPLS-based interconnection styles (referred to as options B and C in IETF RFC 4364). _ 1IETF RFC 2547, which was the informational RFC that described MPLS/BGP VPNs, was superseded by the standards track IETF RFC 43
