ITU-T G 9905 AMD 1-2016 Centralized metric-based source routing Amendment 1 (Study Group 15).pdf

《ITU-T G 9905 AMD 1-2016 Centralized metric-based source routing Amendment 1 (Study Group 15).pdf》由会员分享，可在线阅读，更多相关《ITU-T G 9905 AMD 1-2016 Centralized metric-based source routing Amendment 1 (Study Group 15).pdf（40页珍藏版）》请在麦多课文档分享上搜索。

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 G.9905 TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU Amendment 1 (11/2016) SERIES G: TRANSMISSION SYSTEMS AND MEDIA, DIGITAL SYSTEMS AND NETWORKS Access networks In premises networks Centralized metric-based source routin

2、g Amendment 1 Recommendation ITU-T G.9905 (2013) Amendment 1 ITU-T G-SERIES RECOMMENDATIONS TRANSMISSION SYSTEMS AND MEDIA, DIGITAL SYSTEMS AND NETWORKS INTERNATIONAL TELEPHONE CONNECTIONS AND CIRCUITS G.100G.199 GENERAL CHARACTERISTICS COMMON TO ALL ANALOGUE CARRIER-TRANSMISSION SYSTEMS G.200G.299

3、INDIVIDUAL CHARACTERISTICS OF INTERNATIONAL CARRIER TELEPHONE SYSTEMS ON METALLIC LINES G.300G.399 GENERAL CHARACTERISTICS OF INTERNATIONAL CARRIER TELEPHONE SYSTEMS ON RADIO-RELAY OR SATELLITE LINKS AND INTERCONNECTION WITH METALLIC LINES G.400G.449 COORDINATION OF RADIOTELEPHONY AND LINE TELEPHONY

4、 G.450G.499 TRANSMISSION MEDIA AND OPTICAL SYSTEMS CHARACTERISTICS G.600G.699 DIGITAL TERMINAL EQUIPMENTS G.700G.799 DIGITAL NETWORKS G.800G.899 DIGITAL SECTIONS AND DIGITAL LINE SYSTEM G.900G.999 MULTIMEDIA QUALITY OF SERVICE AND PERFORMANCE GENERIC AND USER-RELATED ASPECTS G.1000G.1999 TRANSMISSIO

5、N MEDIA CHARACTERISTICS G.6000G.6999 DATA OVER TRANSPORT GENERIC ASPECTS G.7000G.7999 PACKET OVER TRANSPORT ASPECTS G.8000G.8999 ACCESS NETWORKS G.9000G.9999 Metallic access networks G.9700G.9799 Optical line systems for local and access networks G.9800G.9899 In premises networks G.9900G.9999 For fu

6、rther details, please refer to the list of ITU-T Recommendations. Rec. ITU-T G.9905 (2013)/Amd.1 (11/2016) i Recommendation ITU-T G.9905 Centralized metric-based source routing Amendment 1 Summary Recommendation ITU-T G.9905 specifies centralized metric based source routing (CMSR), a proactive, laye

7、r 2 multi-hop routing protocol. CMSR is a proactive routing protocol which can find and maintain reliable routes considering the link quality of both directions. The routing control packet overhead of CMSR is quite low compared to existing proactive routing protocols such as optimized link state rou

8、ting (OLSR), so that it can be applied for large-scale networks even on narrow band power line communication (PLC) networks. Amendment 1 adds the following features: a PAN-INFO sub-message in the Hello message to notify information on the coordinator or network status, message formats for non-6LoWPA

9、N networks, and a procedure for inter-node communication and upstream source routing. History Edition Recommendation Approval Study Group Unique ID* 1.0 ITU-T G.9905 2013-08-29 15 11.1002/1000/12007 1.1 ITU-T G.9905 (2013) Amd. 1 2016-11-13 15 11.1002/1000/13110 _ * To access the Recommendation, typ

10、e the URL http:/handle.itu.int/ in the address field of your web browser, followed by the Recommendations unique ID. For example, http:/handle.itu.int/11.1002/1000/11830-en. ii Rec. ITU-T G.9905 (2013)/Amd.1 (11/2016) FOREWORD The International Telecommunication Union (ITU) is the United Nations spe

11、cialized agency in the field of 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

12、 with a view to standardizing telecommunications 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

13、Recommendations is covered by the 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 Recommendation, the expression “Administration“ is used f

14、or conciseness to indicate both a telecommunication administration and a recognized operating agency. 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 Re

15、commendation is achieved when all of these mandatory 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 Recommendation is required of any

16、 party. INTELLECTUAL PROPERTY RIGHTSITU draws attention to the possibility that the practice or implementation 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 Propert

17、y Rights, whether asserted by ITU members or others outside of the Recommendation development process. As of the date of approval of this Recommendation, ITU had received notice of intellectual property, protected by patents, which may be required to implement this Recommendation. However, implement

18、ers are cautioned that this may not represent the latest information and are therefore strongly urged to consult the TSB patent database at http:/www.itu.int/ITU-T/ipr/. ITU 2017 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written pe

19、rmission of ITU. Rec. ITU-T G.9905 (2013)/Amd.1 (11/2016) iii Table of Contents Page 1 Scope . 1 2 References . 1 3 Definitions 1 3.1 Terms defined elsewhere 1 3.2 Terms defined in this Recommendation . 1 4 Abbreviations and acronyms 2 5 Protocol overview . 2 5.1 Outline of operation 2 5.2 Table ove

20、rview . 5 5.3 Signalling overview 6 5.4 Protocol parameters 7 6 Table and information base 7 6.1 Neighbour table 7 6.2 Route table 8 7 Message format . 8 7.1 CMSR source route header . 9 7.2 CMSR message 10 8 Procedure 16 8.1 Hello message exchange . 16 8.2 Topology report message transmission 20 8.

21、3 Route Error message transmission . 21 8.4 Link break determination . 21 8.5 Route break determination . 21 9 Packet transmission 21 9.1 Unicast packet 21 9.2 Broadcast/multicast packet . 22 10 Configuration parameters . 22 Annex A Routing procedure for ITU-T G.9903 . 23 A.1 Defining parameter . 23

22、 A.2 Mesh routing . 23 A.3 Transmission of IPv6 packet triggered by ADPD-DATA primitive 25 A.4 Packet transmission and reception triggered by non-default routing entity . 26 A.5 Interface between the ITU-T G.9903 adaptation layer and ITU-T G.9905 26 Annex B Applying CMSR to a network without 6LoWPAN

23、 . 30 B.1 Packet format 30 B.2 CMSR message 30 Rec. ITU-T G.9905 (2013)/Amd.1 (11/2016) 1 Recommendation ITU-T G.9905 Centralized metric-based source routing Amendment 1 Editorial note: This is a complete-text publication. Modifications introduced by this amendment are shown in revision marks relati

24、ve to Recommendation ITU-T G.9905 (2013). 1 Scope This Recommendation specifies centralized metric based source routing (CMSR), a proactive, layer 2 multi-hop routing protocol. 2 References The following ITU-T Recommendations and other references contain provisions which, through reference in this t

25、ext, constitute provisions of this Recommendation. At the time of publication, the editions indicated were valid. All Recommendations and other references are subject to revision; users of this Recommendation are therefore encouraged to investigate the possibility of applying the most recent edition

26、 of the Recommendations and other references listed below. A list of the currently valid ITU-T Recommendations is regularly published. The reference to a document within this Recommendation does not give it, as a stand-alone document, the status of a Recommendation. ITU-T G.9903 Recommendation ITU-T

27、 G.9903 (2014), Narrowband orthogonal frequency division multiplexing power line communication transceivers for G3-PLC networks. IETF RFC 4944 IETF RFC 4944 (2007), Transmission of IPv6 Packets over IEEE 802.15.4 Networks. IETF RFC 6282 IETF RFC 6282 (2011), Compression Format for IPv6 Datagrams ove

28、r IEEE 802.15.4-Based Networks. 3 Definitions 3.1 Terms defined elsewhere None. 3.2 Terms defined in this Recommendation This Recommendation defines the following terms: 3.2.1 1WAY link: A link between neighbour nodes for which only the incoming link cost is available. 3.2.2 2WAY link: A link betwee

29、n neighbour nodes for which both incoming and outgoing link costs are available. 3.2.3 Hello message: A message transmitted by each node in order both to notify its existence and to exchange link cost and route information with neighbour nodes. 3.2.4 LC incoming: The cost of a one-way link from a ne

30、ighbour node. 3.2.5 LC outgoing: The cost of a one-way link toward a neighbour node. 2 Rec. ITU-T G.9905 (2013)/Amd.1 (11/2016) 3.2.6 link: A link between two nodes exists if either can receive control messages from the other, according to this specification. 3.2.7 link cost (LC): The cost of a link

31、 between a pair of nodes, calculated from bidirectional link quality. The LC value used is the greater of “LC incoming“ and “LC outgoing“. 3.2.8 LOST link: A broken link where communication is no longer possible. 3.2.9 node: Communication equipment, including the personal area network (PAN) coordina

32、tor, which communicates using the CMSR protocol according to this specification. 3.2.10 provisional route cost: The provisional route quality between a node and the coordinator, equal to the sum of the route cost from a neighbour node to the coordinator and the LC incoming from the neighbour node. 3

33、.2.11 route cost: The total route quality between a node and the coordinator, equal to the sum of all link costs in the route from the node to the coordinator. 3.2.12 topology report message: A message transmitted to the coordinator (using unicast) that contains route and neighbour node information.

34、 4 Abbreviations and acronyms This Recommendation uses the following abbreviations and acronyms: CMSR Centralized Metric based Source Routing LC Link Cost MAC Media Access Control NSDU Network Service Data Unit PAN Personal Area Network PLC Power Line Communication 5 Protocol overview Multi-hop rout

35、ing protocols are a key feature of communication for advanced metering applications over power line communications (PLCs). For a large-scale PLC network, e.g., PLC deployment in a large-scale apartment building, a robust and low overhead routing protocol is required in order to achieve reliable mete

36、ring. This Recommendation addresses the following main objectives: Perform mesh-under proactive routing on 6LoWPAN in IPv6 networks, and communicate using 16-bit short addresses used by 6LoWPAN. Discover a bidirectional route between a node and a coordinator, taking bidirectional link quality into a

37、ccount. Establish and maintain multiple reliable routes in case route break occurs. Generate control packets which increase as only O(N) for route discovery and maintenance (with N being the number of nodes present in the network). Deliver data packets with source routing and/or hop-by-hop routing.

38、5.1 Outline of operation CMSR performs mesh-under routing basically on 6LoWPAN in IPv6 networks, and communicates using 16-bit short addresses used by 6LoWPAN., but it can also work in a network without 6LoWPAN. The usage for non-6LoWPAN networks is defined in Annex B. In order to perform Rec. ITU-T

39、 G.9905 (2013)/Amd.1 (11/2016) 3 neighbour node detection and route discovery, a Hello message is used for exchanging route and link quality information between nodes, whereas a topology report message is used to notify the coordinator. The coordinator and nodes maintain neighbour tables for storing

40、 information on neighbour nodes, and route tables for storing route information. Each node determines an optimal route based on the link quality and the number of hops to the coordinator. 5.1.1 Route discovery Route discovery is carried out with the three steps shown in Figure 5-1. Figure 5-1 Overvi

41、ew of route discovery steps Step 1: Hello message exchange and neighbour table update Each node periodically transmits the Hello message as a 1-hop broadcast message with the interval of HELLO_INTERVAL (or HELLO_INTERVAL_FAST as mentioned in clause 8.1.1). In order to avoid a permanent collision of

42、Hello messages, each node randomly shifts the transmission timing. The maximum timing shift is defined by HELLO_JITTER. For route discovery, the node establishes a 2WAY link with the node which already has a route to the coordinator. Figure 5-2 shows how the 2WAY link is established. The node that r

43、eceives the Hello message stores the information included in the Hello message in the neighbour table. When the node receives a Hello message from its neighbour node for the first time, the link between the nodes is considered as a 1WAY link (meaning that the node has measured the LC incoming from t

44、hat neighbour node but does not know the LC outgoing to that neighbour node). The receiving node calculates the provisional route cost as the sum of the route costs in the received Hello messages and the measured LC incoming. The status, LC incoming and provisional route cost are recorded in the nei

45、ghbour table (first phase in Figure 5-2). The node selects the neighbour nodes based on the provisional route costs, i.e., neighbour nodes with lowest provisional route costs. Up to LINK_MAX_PREFERRED neighbour nodes may be selected. The node sends a Hello message with the link request (LINK_REQ sub

46、-message) to the selected neighbour nodes to obtain the LC outgoing. Upon reception of the LINK_REQ sub-message, the neighbour nodes record the LC incoming and LC outgoing according to the received message (second phase in Figure 5-2). The neighbour nodes transmit LINK_REP sub-messages including the

47、 LC incoming to the originator of the LINK_REQ. The originator node stores the LC incoming in the received LINK_REP sub-message as LC outgoing, and sets the link status as “2WAY“ (third phase in Figure 5-2). Note that the LINK_REQ and LINK_REP sub-messages are transmitted in the Hello message that i

48、s periodically transmitted with the interval of HELLO_INTERVAL (or HELLO_INTERVAL_FAST). 4 Rec. ITU-T G.9905 (2013)/Amd.1 (11/2016) G . 9 9 0 5 (1 3 )_ F 5 -2 Set N o d e 2 L C In co mi n g en t ry acco rd i n g t o l i n kq u al i t y o f recei v ed H E L L O Set N o d e 2 stat u s en tryt o 1 W A

49、YN o d e 2HELLO Set N o d e 1 L C In co mi n g en tryacco rd i n g t o l i n k q u al i t y o f recei v edH E L L O an d L C O u t g o i n g en t ry t oL C v al u e i n L IN K _ RE Q Set N o d e 1 stat u s to 2 W A YL IN K _ RE Q :L C In co mi n g (fro m N o d e 2 ),A d d r2N o d e 2 L IN K _ RE P:L C In co mi n g (fro m N o d e 1 ),A d d r1 Set N o d e 2 L C O u tg o in g en t ry acco rd i n g t o v al u e i nL IN K _ RE P Set N o d e 2 stat u s