1、 I n t e r n a t i o n a l T e l e c o m m u n i c a t i o n U n i o n ITU-T Q.3712 TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (08/2016) SERIES Q: SWITCHING AND SIGNALLING Signalling requirements and protocols for SDN Resource control protocols Scenarios and signalling requirements of unified i
2、ntelligent programmable interface for IPv6 Recommendation ITU-T Q.3712 ITU-T Q-SERIES RECOMMENDATIONS SWITCHING AND SIGNALLING SIGNALLING IN THE INTERNATIONAL MANUAL SERVICE Q.1Q.3 INTERNATIONAL AUTOMATIC AND SEMI-AUTOMATIC WORKING Q.4Q.59 FUNCTIONS AND INFORMATION FLOWS FOR SERVICES IN THE ISDN Q.6
3、0Q.99 CLAUSES APPLICABLE TO ITU-T STANDARD SYSTEMS Q.100Q.119 SPECIFICATIONS OF SIGNALLING SYSTEMS No. 4, 5, 6, R1 AND R2 Q.120Q.499 DIGITAL EXCHANGES Q.500Q.599 INTERWORKING OF SIGNALLING SYSTEMS Q.600Q.699 SPECIFICATIONS OF SIGNALLING SYSTEM No. 7 Q.700Q.799 Q3 INTERFACE Q.800Q.849 DIGITAL SUBSCRI
4、BER SIGNALLING SYSTEM No. 1 Q.850Q.999 PUBLIC LAND MOBILE NETWORK Q.1000Q.1099 INTERWORKING WITH SATELLITE MOBILE SYSTEMS Q.1100Q.1199 INTELLIGENT NETWORK Q.1200Q.1699 SIGNALLING REQUIREMENTS AND PROTOCOLS FOR IMT-2000 Q.1700Q.1799 SPECIFICATIONS OF SIGNALLING RELATED TO BEARER INDEPENDENT CALL CONT
5、ROL (BICC) Q.1900Q.1999 BROADBAND ISDN Q.2000Q.2999 SIGNALLING REQUIREMENTS AND PROTOCOLS FOR THE NGN Q.3000Q.3709 SIGNALLING REQUIREMENTS AND PROTOCOLS FOR SDN Q.3710Q.3899 Resource control protocols Q.3710Q.3739 TESTING SPECIFICATIONS Q.3900Q.4099 For further details, please refer to the list of I
6、TU-T Recommendations. Rec. ITU-T Q.3712 (08/2016) i Recommendation ITU-T Q.3712 Scenarios and signalling requirements of unified intelligent programmable interface for IPv6 Summary Recommendation ITU-T Q.3712 describes the scenarios and signalling requirements of unified intelligent programmable int
7、erface for IPv6 service deployment. History Edition Recommendation Approval Study Group Unique ID* 1.0 ITU-T Q.3712 2016-08-29 11 11.1002/1000/12990 Keywords IPv6, SDN, transition. * To access the Recommendation, type the URL http:/handle.itu.int/ in the address field of your web browser, followed b
8、y the Recommendations unique ID. For example, http:/handle.itu.int/11.1002/1000/11830-en. ii Rec. ITU-T Q.3712 (08/2016) FOREWORD The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of telecommunications, information and communication technologies (I
9、CTs). 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 telecommunications on a worldwide basis. The World Telecommunicatio
10、n 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 the procedure laid down in WTSA Resolution 1. In some areas of info
11、rmation technology which fall within ITU-Ts purview, the necessary standards are prepared on a collaborative basis with ISO and IEC. NOTE In this Recommendation, the expression “Administration“ is used for conciseness to indicate both a telecommunication administration and a recognized operating age
12、ncy. Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain mandatory provisions (to ensure, e.g., interoperability or applicability) and compliance with the Recommendation is achieved when all of these mandatory provisions are met. The words “shall“ or som
13、e 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 Recommendation is required of any party. INTELLECTUAL PROPERTY RIGHTSITU draws attention to the possibility that the practice or i
14、mplementation of this Recommendation 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 others outside of the Recommendation development pro
15、cess. As of the date of approval of this Recommendation, ITU had not received notice of intellectual property, protected by patents, which may be required to implement this Recommendation. However, implementers are cautioned that this may not represent the latest information and are therefore strong
16、ly urged to consult the TSB patent database at http:/www.itu.int/ITU-T/ipr/. ITU 2016 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of ITU. Rec. ITU-T Q.3712 (08/2016) iii Table of Contents Page 1 Scope . 1 2 Referen
17、ces . 1 3 Definitions 1 3.1 Terms defined elsewhere 1 3.2 Terms defined in this Recommendation . 1 4 Abbreviations and acronyms 1 5 Conventions 2 6 The deployment scenario and use cases . 2 6.1 Evolve from one IPv6 transition scenario to another . 2 6.2 Multiple transition mechanisms co-exist 2 7 Th
18、e signalling architecture . 4 8 Signalling requirements 4 8.1 Component functions 4 8.2 Interface requirements 4 9 The signalling protocol procedures 6 9.1 Information model 7 9.2 Operations . 7 Appendix I Protocol profiles for this Recommendation . 8 Bibliography. 9 Rec. ITU-T Q.3712 (08/2016) 1 Re
19、commendation ITU-T Q.3712 Scenarios and signalling requirements of unified intelligent programmable interface for IPv6 1 Scope This Recommendation describes the scenarios and signalling requirements of unified intelligent programmable interface for IPv6 service deployment. The example signalling pro
20、tocol procedures at this interface will also be described in this Recommendation to support protocol unaware flow forwarding in the data plane. The IPv6 technologies supported in this Recommendation will include, but not be limited to, the following: dual-stack lite (DS-Lite), IPv6 only, IPv6 rapid
21、deployment (6rd), IPv4 residual deployment (4rd), mapping of address and port - encapsulation mode (MAP-E), mapping of address and port - translation mode (MAP-T), lightweight 4over6 (lw4over6) and 464XLAT. 2 References None. 3 Definitions 3.1 Terms defined elsewhere This Recommendation uses the fol
22、lowing term defined elsewhere: 3.1.1 software-defined networking b-ITU-T Y.3300: A set of techniques that enables to directly program, orchestrate, control and manage network resources, which facilitates the design, delivery and operation of network services in a dynamic and scalable manner. 3.2 Ter
23、ms defined in this Recommendation None. 4 Abbreviations and acronyms This Recommendation uses the following abbreviations and acronyms: ALG Application Level Gateway App Application DS-Lite Dual-Stack Lite lw4over6 Lightweight 4over6 NAT64 Network Address Translation 64 NETCONF Network configuration
24、 protocol RG Residential Gateway SDN Software-Defined Networking TCP Transmission Control Protocol UDP User Datagram Protocol 4rd IPv4 Residual Deployment 6rd IPv4 Rapid Deployment 2 Rec. ITU-T Q.3712 (08/2016) 5 Conventions None. 6 The deployment scenario and use cases 6.1 Evolve from one IPv6 tran
25、sition scenario to another During the IPv6 transition period, the network has three types: IPv4-only, dual-stack and IPv6-only. The networks should support both IPv4 services and IPv6 services at each stage. There are multiple IPv6 transition technologies for different network scenarios (e.g., IPv4
26、network for IPv4/IPv6 user access, IPv6 network for IPv4/IPv6 user access, IPv4 servers for IPv6 visitors). Different network scenarios will co-exist during IPv6 transition which means the IPv6 transition device should support multiple IPv6 transition technologies. The following are six possible sce
27、narios of IPv6 transition: 1) IPv6 host visits IPv6 servers via IPv4 access network; 2) IPv4 host visits IPv4 servers via IPv4 NAT dual-stack network; 3) IPv6 host visit IPv6 servers via IPv6 network; 4) IPv4 host visits IPv4 servers via IPv6 access network; 5) IPv6 host visits IPv6 servers via IPv4
28、 access network; 6) IPv4 host and IPv6 host interaction. It is not necessary that every operator goes through each scenario one by one. For example, some operators may start from scenario 1), and some may start directly from scenario 2) or scenario 4). However, since the final stage (target) is an I
29、Pv6-only access network, one still needs to go through multiple scenarios from a long-term perspective. In such a case, the operator should either upgrade existing devices to support new features, or replace them with new ones. In particular, when the operators network consists of devices from diffe
30、rent vendors, it is hard to guarantee that all legacy devices can be upgraded at the same time. This is costly and complicated. 6.2 Multiple transition mechanisms co-exist Currently, there are multiple transition mechanisms in the industry, e.g., DS-Lite, lw4over6, mapping of address and port (MAP)/
31、4rd, network address translation 64 (NAT64). In the transition from one scenario to another, different mechanisms may have different impacts on user experience. For example, DS-Lite would have some impact due to address sharing as compared with 6rd mechanisms, and NAT64 would have an additional impa
32、ct due to application level gateway (ALG) issues. Operators need to offer a fallback mechanism to guarantee the same level of user experience when there are complaints from subscribers. Therefore, it is required to support multiple transition mechanisms in the same area (even in the same device). An
33、other use case is that multiple scenarios may exist in the same stage. For example, if both IPv6-only devices and IPv4-only hosts are in the same area with limited public IPv4 address, then NAT64 and NAT44 (or DS-Lite) are both required to achieve IPv4 service connectivity. Rec. ITU-T Q.3712 (08/201
34、6) 3 Figure 6-1 Scenario and use case of this Recommendation The unified intelligent IPv6 deployment scenario offers end-to-end service deployment and management. The residential gateway (RG), the IP edge and the service edge are flow-forwarding enabled. The hardware can be unified for different IPv
35、6 transition technologies via flow-forwarding. IPv6 transition technologies can be plugged into the controllers. The flow-forwarding enabled devices do not need to change during the various stages of IPv6 transition. The northbound interface is essential to support the eco-system of software-defined
36、 networking (SDN) by allowing various SDN-related applications to be plugged in various vendor controllers. The goal is to make the controller controlled infrastructure to be an open platform for more innovations by allowing applications to be developed with the best network support. Several OpenFlo
37、w switches are deployed and located at the edge of network, as shown in Figure 6-1. The OpenFlow protocol may be extended mainly to support an IP tunnelling approach for transition purposes. The OpenFlow switches process the incoming packets based on the flow tables delivered by the SDN controller u
38、pon the request of an IPv6-transition application (App). The controller in the control layer provides an interface to the IPv6 transition App, enabling it to modify traffic processing using OpenFlow. Specifically, the controller provides an OpenFlow driver that enables the IPv6 transition App to ins
39、truct all SDN-enabled device how to treat traffic, thus making it possible to flexibly choose the particular transition mechanism to be applied, and to select the parameters governing it. The OpenFlow driver includes OpenFlow protocol specific tasks: listens for OpenFlow connections, creates the cha
40、nnel, keeps alive, proxy between the OpenFlow wire format and the solution internal information representation (e.g., rules, events). It is a basic function of the SDN controller. The process shown for this case is generic. A flow can be identified by part of the layer 2 (L2) to layer 4 (L4) packet
41、header information. For example, all packets to a particular subscriber can be treated as belonging to the same flow in an SDN-enabled network. SDN provides a programmable platform for service deployment which can reduce new issues arising in the IPv6 transition. 4 Rec. ITU-T Q.3712 (08/2016) 7 The
42、signalling architecture Figure 7-1 Signalling interface IPv6 transition technologies are presented as software Apps and are loaded into the control layer which is responsible for IPv6 application/transition support function via plug-in method. An IPv6 application/transition support function interfac
43、e (Sn), which may use network configuration protocol (NETCONF)/YANG, describes IPv6 application/transition support function needed, which is independent of IPv6 application/transition technologies. The App layer generates the operation request based on the IPv6 application/transition support functio
44、n data model configured, and sends the request to the IPv6 application/transition support function in the control layer. The IPv6 application/transition support function enables the Apps to manipulate the traffic via the Sn interface. 8 Signalling requirements 8.1 Component functions 8.1.1 App layer
45、 The application modules in the App layer provide the abstracted application program interfaces (APIs) and/or user functions. It receives the packet about the IPv6 transition technologies APP of new IPv6 flows from the control layer after the control layer receives the events from the network device
46、s in the data plane. Then it sends appropriate instructions to the SDN-enabled device via the control layer and the Sn interface. 8.1.2 Control layer The control layer provides a northbound interface (Sn) that enables the IPv6 transition technologies App to modify the traffic using OpenFlow. It rece
47、ives the events from the network devices and sends it to the App layer if necessary. After receiving the instructions from the App layer, the control layer translates the commands of the IPv6 transition technologies APP to a command that can be executed by the SDN-enabled device. 8.2 Interface requi
48、rements The control layer provides a northbound interface (Sn) that enables the IPv6-transition App to modify traffic at the data plane using OpenFlow. Specifically, the control layer provides an OpenFlow driver that enables the IPv6-transition App to decide how the SDN-enabled packet-forwarding dev
49、ices treat traffic using the Sn interface. This interface is used to provide an IPv6 application/transition support function interface to any IPv6-transition application. It mainly provides the following functions: Registration and removal function for applications; IPv6 application/transition support function data model for packets and flow tables interaction between controller and applications; Rec. ITU-T Q.3712 (08/2016) 5 Adapting packet-in events into neutral events in the interface; Supporting the installation function for applica
