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 Series Q TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU Supplement 67 (04/2015) SERIES Q: SWITCHING AND SIGNALLING Framework of signalling for software-defined networking ITU-T Q-series Recommendations Supplement 67 ITU-T
2、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.60Q.99 CLAUSES APPLICABLE TO ITU-T STANDARD SYSTEMS Q.100Q.119 SPECIFICATIONS
3、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 SUBSCRIBER SIGNALLING SYSTEM No. 1 Q.850Q.999 PUBLIC LAND MOBILE NETWORK Q.1000Q.109
4、9 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 CONTROL (BICC) Q.1900Q.1999 BROADBAND ISDN Q.2000Q.2999 SIGNALLING REQUIREMENTS A
5、ND PROTOCOLS FOR THE NGN Q.3000Q.3999 For further details, please refer to the list of ITU-T Recommendations. Q series Supplement 67 (04/2015) i Supplement 67 to ITU-T Q-series Recommendations Framework of signalling for software-defined networking Summary Supplement 67 to ITU-T Q-series Recommendat
6、ions provides the framework of signalling for software-defined networking (SDN) by specifying the signalling requirements and architecture for SDN, as well as the interfaces and signalling protocol procedures. This Supplement should also be helpful in enabling the development of a signalling protoco
7、l(s) capable of supporting traffic flows. History Edition Recommendation Approval Study Group Unique ID* 1.0 ITU-T Q Suppl. 67 2015-04-29 11 11.1002/1000/12503 Keywords SDN, signalling model, software-defined networking. _ * To access the Recommendation, type the URL http:/handle.itu.int/ in the add
8、ress field of your web browser, followed by the Recommendations unique ID. For example, http:/handle.itu.int/11.1002/1000/11830-en. ii Q series Supplement 67 (04/2015) FOREWORD The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of telecommunications
9、, 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 telecommunications o
10、n 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 the procedure laid d
11、own 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 telecommunication a
12、dministration 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 mandatory provision
13、s 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 RIGHTSITU draws attention to the po
14、ssibility 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 others outside of the p
15、ublication 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 latest information and
16、are therefore strongly 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. Q series Supplement 67 (04/2015) iii Table of Contents P
17、age 1 Scope . 1 2 References . 1 3 Definitions 1 3.1 Terms defined elsewhere 1 3.2 Terms defined in this Supplement 1 4 Abbreviations and acronyms 2 5 Conventions 3 6 Signalling requirements and scenarios . 3 6.1 SDN-enabled network 3 6.2 SDN-enabled overlay network . 3 6.3 SDN controller related re
18、quirements and scenarios . 3 6.4 Software-defined mobile network 6 7 Signalling model . 7 8 Description of interfaces in the signalling model . 8 8.1 Sa 8 8.2 Sn 8 8.3 Sew . 8 8.4 Ss 9 8.5 Sma . 9 8.6 Smo . 9 8.7 Smc . 9 8.8 Smn . 9 9 Signalling protocol procedures . 9 9.1 Procedure for VM live migr
19、ation . 9 Appendix I Scenarios and corresponding requirements of Ss for seamless handover 11 I.1 IEEE 802.21 media independent service (MIS) . 11 I.2 Signalling protocol procedures . 12 Appendix II Development methodology of this Supplement . 13 Bibliography. 14 Q series Supplement 67 (04/2015) 1 Su
20、pplement 67 to ITU-T Q-series Recommendations Framework of signalling for software-defined networking 1 Scope This Supplement provides the framework of signalling for software-defined networking (SDN) by specifying the signalling requirements and architecture for SDN, as well as the interfaces and s
21、ignalling protocol procedures. These requirements and the signalling information elements identified will enable the development of a signalling protocol(s) capable of supporting traffic flows. 2 References ITU-T M.3400 Recommendation ITU-T M.3400 (2000), TMN management functions. ITU-T Y.3300 Recom
22、mendation ITU-T Y.3300 (2014), Framework of Software-Defined Networking. ITU-T Y.3500 Recommendation ITU-T Y.3500 (2014), Information technology Cloud Computing Overview and Vocabulary. ITU-T Y.3501 Recommendation ITU-T Y.3501 (2013), Cloud computing framework and high-level requirements. ITU-T Y.35
23、12 Recommendation ITU-T Y.3512 (2014), Cloud computing Functional requirements of Network as a Service. 3 Definitions 3.1 Terms defined elsewhere This Supplement uses the following terms defined elsewhere: 3.1.1 Communication as a Service (CaaS) ITU-T Y.3500: Cloud service category in which the capa
24、bility provided to the cloud service customer is real time interaction and collaboration. NOTE CaaS can provide both application capabilities type and platform capabilities type. 3.1.2 Network as a Service (NaaS) ITU-T Y.3500: Cloud service category in which the capability provided to the cloud serv
25、ice customer is transport connectivity and related network capabilities. NOTE NaaS can provide any of the three cloud capabilities types. 3.1.3 service chain ITU-T Y.3512: An ordered set of functions that is used to enforce differentiated traffic handling policies for a traffic flow. 3.1.4 software-
26、defined networking (SDN) 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 Terms defined in this Supplement This Supplem
27、ent defines the following terms: 3.2.1 middlebox: A computer networking device that caches, transforms, inspects, filters, or otherwise manipulates traffic for purposes other than packet forwarding. 3.2.2 orchestration: Functionality that provides the automated management and coordination of network
28、 resources and services. 2 Q series Supplement 67 (04/2015) 3.2.3 white-box: A general purpose data processing device that provides reconfigurable and customizable middle box functions (e.g., network address translation (NAT), cache, deep packet inspection (DPI), intrusion detection systems (IDS), e
29、tc.) for purposes other than packet forwarding. It can be implemented in a virtualized manner. 4 Abbreviations and acronyms This Supplement uses the following abbreviations and acronyms: ACL Access Control List API Application Programming Interface AS Autonomous System BGP Border Gateway Protocol Ca
30、aS Communication as a Service CE Control Entity DPI Deep Packet Inspection FCAPS Fault, Configuration, Accounting, Performance and Security FE Functional Entity IDS Intrusion Detection Systems IoT Internet of Things IP Internet Protocol LBS Location-Based Service M2M Machine to Machine MIS Media Ind
31、ependent Service MN Mobile Node MPLS Multi-Protocol Label Switching NaaS Network as a Service NAT Network Address Translation NE Network Entity NFV Network Function Virtualization ONF Open Networking Foundation QoS Quality of Service RAN Radio Access Network SDN Software-Defined Networking SLA Servi
32、ce Level Agreement VLAN Virtual Local Area Network VM Virtual Machine VPN Virtual Private Network Q series Supplement 67 (04/2015) 3 5 Conventions In this Supplement: The keywords “is required to“ indicate a requirement which must be strictly followed and from which no deviation is permitted, if con
33、formance to this Supplement is to be claimed. The keywords “is recommended“ indicate a requirement which is recommended but which is not absolutely required. Thus, this requirement need not be present to claim conformance. The keywords “can optionally“ indicate an optional requirement which is permi
34、ssible, without implying any sense of being recommended. This term is not intended to imply that the vendors implementation must provide the option, and the feature can be optionally enabled by the network operator/service provider. Rather, it means the vendor may optionally provide the feature and
35、still claim conformance with this Supplement. 6 Signalling requirements and scenarios 6.1 SDN-enabled network In the SDN-enabled network scenario, the centralized SDN controller creates a traffic path from one edge of the network to the other edge of the network using certain protocols over the sout
36、hbound interface, such as OpenFlow b-ONF, which programs this traffic on each node in the path, including edge, aggregation and core switches/routers. The first packet of the new traffic is sent to a centralized SDN controller which applies policy, computes the paths and uses the southbound interfac
37、e to direct this traffic into each node on the path. Considering that this approach brings several problems, the following issues are recommended to be solved: It creates an explosion of forwarding states on the physical switches/routers; The SDN controller should communicate with each of the physic
38、al switches/routers in the path when a new traffic is needed to be programed; This model unavoidably brings extra latency. 6.2 SDN-enabled overlay network In the SDN-enabled overlay network scenario, the centralized SDN controller uses overlay tunnels to virtualize the network. These tunnels general
39、ly terminate in virtual switches/routers, and can also terminate in physical switches/routers. This scenario reduces the size of the forwarding states in the physical underlay nodes and may not touch the physical switches when adding a new tenant or virtual machine (VM). Most importantly, the SDN co
40、ntroller provides a seamless migration path for introducing SDN into the existing production networks. There are multiple data plane protocols which can be used to create overlay tunnels. Taking OpenFlow as an example, it can just be deployed at the edge of the network and does not touch the aggrega
41、tion and core physical switches/routers. In that case, OF-Config b-ONF is used to create overlay tunnels and OpenFlow is used to program traffic into the tunnels. However, in this scenario, it is very difficult to provide per-tenant or per-VM quality of service (QoS), because every packet is encapsu
42、lated into a tunnel. Support of fine-grained queuing is recommended in order to isolate tenants and provide per-tenant QoS, respectively. 6.3 SDN controller related requirements and scenarios 6.3.1 Hybrid network This deployment model allows the co-existence of traditional environments of closed ven
43、dors router/switches and OpenFlow-enabled devices. This hybrid approach refers to the interconnection 4 Q series Supplement 67 (04/2015) of both the control and data planes of legacy and new network elements, which can be regarded as the smooth migration for the existing network. Figure 6-1 depicts
44、the hybrid network model. The legacy controller mentioned in this figure is not limited to the server and can be extended to other device types. The route reflector for example, which is the most popular way to distribute border gateway patrol (BGP) routes between routers of the same autonomous syst
45、em (AS), can be regarded as a legacy controller. It is required to provide the dedicated gateway-like component between the existing legacy controllers and OpenFlow controllers in the new control plane. Q S u p p l. 6 7 ( 1 5 ) _ F 6 - 1L e g a c yc o n t r o l l e rL e g a c y c o n t r o l l i n k
46、O p e n F l o w c o n t r o l l i n kD a t a p l a n e l i n kS D N c o n t r o l l e rO p e n F l o w - e n a b l e d d e v i c e sL e g a c y s w i t c h / r o u t e rFigure 6-1 Hybrid network model 6.3.2 Interactions between different SDN domains With more deployments in carrier-grade networks, i
47、t is impossible for any single SDN controller to contain all of the operational states for the entire system. Therefore, the issue of interoperability of SDN controllers (also known as east-west interface) becomes critical. It is necessary to establish controller nodes peering either within the same
48、 administrative domain (intra-domain), or between administrative domains (inter-domain) in a multi-vender environment. The east-west interface signalling should guarantee the synchronization of states among the federated controller nodes. If there is transient inconsistency, it is necessary to make
49、a local decision on which control instance state to utilize. Considering the combined advantages of scalability, high-availability and low-cost, the requirement of smooth migration from the existing network should be taken into account. It is required to reduce network complexity, simplify operation, prevent loss of performance, and integrate SDN systems with the existing infrastructure and service logic in the carrier-grade network, such as BGP, multi-protocol label switching
