--- 1/draft-ietf-mpls-residence-time-09.txt 2016-07-05 11:16:11.391429813 -0700 +++ 2/draft-ietf-mpls-residence-time-10.txt 2016-07-05 11:16:11.451431320 -0700 @@ -1,25 +1,25 @@ MPLS Working Group G. Mirsky Internet-Draft S. Ruffini Intended status: Standards Track E. Gray -Expires: October 30, 2016 Ericsson +Expires: January 6, 2017 Ericsson J. Drake Juniper Networks S. Bryant Independent A. Vainshtein ECI Telecom - April 28, 2016 + July 5, 2016 Residence Time Measurement in MPLS network - draft-ietf-mpls-residence-time-09 + draft-ietf-mpls-residence-time-10 Abstract This document specifies G-ACh based Residence Time Measurement and how it can be used by time synchronization protocols being transported over MPLS domain. Residence time is the variable part of propagation delay of timing and synchronization messages and knowing what this delay is for each message allows for a more accurate determination of the delay to be @@ -34,21 +34,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on October 30, 2016. + This Internet-Draft will expire on January 6, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -77,37 +77,36 @@ 4.7. RTM_SET TLV . . . . . . . . . . . . . . . . . . . . . . . 11 4.7.1. RTM_SET Sub-TLVs . . . . . . . . . . . . . . . . . . 13 5. Data Plane Theory of Operation . . . . . . . . . . . . . . . 16 6. Applicable PTP Scenarios . . . . . . . . . . . . . . . . . . 16 7. One-step Clock and Two-step Clock Modes . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8.1. New RTM G-ACh . . . . . . . . . . . . . . . . . . . . . . 19 8.2. New RTM TLV Registry . . . . . . . . . . . . . . . . . . 19 8.3. New RTM Sub-TLV Registry . . . . . . . . . . . . . . . . 20 8.4. RTM Capability sub-TLV in OSPFv2 . . . . . . . . . . . . 20 - 8.5. RTM Capability sub-TLV in OSPFv3 . . . . . . . . . . . . 21 - 8.6. IS-IS RTM Application ID . . . . . . . . . . . . . . . . 21 - 8.7. RTM_SET Sub-object RSVP Type and sub-TLVs . . . . . . . . 21 - 8.8. RTM_SET Attribute Flag . . . . . . . . . . . . . . . . . 22 - 8.9. New Error Codes . . . . . . . . . . . . . . . . . . . . . 23 + 8.5. IS-IS RTM Application ID . . . . . . . . . . . . . . . . 21 + 8.6. RTM_SET Sub-object RSVP Type and sub-TLVs . . . . . . . . 21 + 8.7. RTM_SET Attribute Flag . . . . . . . . . . . . . . . . . 22 + 8.8. New Error Codes . . . . . . . . . . . . . . . . . . . . . 22 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 - 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 - 11.1. Normative References . . . . . . . . . . . . . . . . . . 24 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 23 11.2. Informative References . . . . . . . . . . . . . . . . . 25 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction Time synchronization protocols, e.g., Network Time Protocol version 4 (NTPv4) [RFC5905] and Precision Time Protocol (PTP) Version 2 - [IEEE.1588.2014] define timing messages that can be used to + [IEEE.1588.2008] define timing messages that can be used to synchronize clocks across a network domain. Measurement of the cumulative time one of these timing messages spends transiting the nodes on the path from ingress node to egress node is termed Residence Time and it is used to improve the accuracy of clock synchronization. (I.e., it is the sum of the difference between the time of receipt at an ingress interface and the time of transmission from an egress interface for each node along the path from ingress node to egress node.) This document defines a new Generalized Associated Channel (G-ACh) value and an associated residence time measurement (RTM) packet that can be used in a Multi-Protocol Label @@ -131,22 +130,22 @@ ACH: Associated Channel TTL: Time-to-Live G-ACh: Generic Associated Channel GAL: Generic Associated Channel Label NTP: Network Time Protocol - ppm: parts per million + ppm: parts per million PTP: Precision Time Protocol LSP: Label Switched Path OAM: Operations, Administration, and Maintenance RRO: Record Route Object RTM: Residence Time Measurement @@ -159,23 +158,23 @@ "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Residence Time Measurement Packet Loss and Delay Measurement for MPLS Networks [RFC6374] can be used to measure one-way or two-way end-to-end propagation delay over LSP or PW. But these measurements are insufficient for use in some applications, for example, time synchronization across a network as defined in the Precision Time Protocol (PTP). In PTPv2 - [IEEE.1588.2014] residence times is accumulated in the + [IEEE.1588.2008] residence times is accumulated in the correctionField of the PTP event message, as defined in - [IEEE.1588.2014], or in the associated follow-up message (or + [IEEE.1588.2008], or in the associated follow-up message (or Delay_Resp message associated with the Delay_Req message) in case of two-step clocks (see the detailed discussion in Section 7). IEEE 1588 uses this residence time to correct the transit time from ingress node to egress node, effectively making the transit nodes transparent. This document proposes a mechanism that can be used as one of types of on-path support for a clock synchronization protocol or to perform one-way measurement of residence time. The proposed mechanism @@ -231,21 +230,21 @@ field with its residence time measurement. Its format is IEEE double precision and its units are nanoseconds. Note that depending on whether the timing procedure is one-step or two-step operation (Section 7), the residence time is either for the timing packet carried in the Value field of this RTM packet or for an associated timing packet carried in the Value field of another RTM packet. o The Type field identifies the type and encapsulation of a timing packet carried in the Value field, e.g., NTP [RFC5905] or PTP - [IEEE.1588.2014]. IANA will be asked to create a sub-registry in + [IEEE.1588.2008]. IANA will be asked to create a sub-registry in Generic Associated Channel (G-ACh) Parameters Registry called "MPLS RTM TLV Registry". o The Length field contains the length, in octets , of the of the timing packet carried in the Value field. o The optional Value field MAY carry a packet of the time synchronization protocol identified by Type field. It is important to note that the packet may be authenticated or encrypted and carried over LSP edge to edge unchanged while the @@ -278,35 +277,35 @@ where Flags field has format 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Flags field format of PTP Packet Sub-TLV o The Type field identifies PTP sub-TLV defined in the Table 19 - Values of messageType field in [IEEE.1588.2014]. + Values of messageType field in [IEEE.1588.2008]. o The Length field of the PTP sub-TLV contains the number of octets of the Value field and MUST be 20. o The Flags field currently defines one bit, the S-bit, that defines whether the current message has been processed by a 2-step node, where the flag is cleared if the message has been handled exclusively by 1-step nodes and there is no follow-up message, and set if there has been at least one 2-step node and a follow-up message is forthcoming. o The PTPType indicates the type of PTP packet carried in the TLV. PTPType is the messageType field of the PTPv2 packet whose values - are defined in the Table 19 [IEEE.1588.2014]. + are defined in the Table 19 [IEEE.1588.2008]. o The 10 octets long Port ID field contains the identity of the source port. o The Sequence ID is the sequence ID of the PTP message carried in the Value field of the message. 4. Control Plane Theory of Operation The operation of RTM depends upon TTL expiry to deliver an RTM packet @@ -358,22 +357,22 @@ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTM | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: RTM Capability sub-TLV - o Type values TBA2 and TBA3 will be assigned by IANA from - appropriate registries for OSPFv2 and OSPFv3 respectively. + o Type value (TBA2) will be assigned by IANA from appropriate + registry for OSPFv2. o Length MUST be set to 4. o RTM (capability) - is a three-bit long bit-map field with values defined as follows: * 0b001 - one-step RTM supported; * 0b010 - two-step RTM supported; @@ -398,44 +397,44 @@ The capability to support RTM on a particular link (interface) is advertised in the OSPFv2 Extended Link Opaque LSA described in Section 3 [RFC7684] via the RTM Capability sub-TLV. Its Type value will be assigned by IANA from the OSPF Extended Link TLV Sub-TLVs registry that will be created per [RFC7684] request. 4.4. RTM Capability Advertisement in OSPFv3 - The capability to support RTM on a particular link (interface) is - advertised in the OSPFv3 be Intra-Area-Prefix TLV, IPv6 Link-Local - Address TLV, or the IPv4 Link-Local Address TLV described in - [I-D.ietf-ospf-ospfv3-lsa-extend] via the RTM Capability sub-TLV. + The capability to support RTM on a particular link (interface) can be + advertised in OSPFv3 using LSA extensions as described in + [I-D.ietf-ospf-ospfv3-lsa-extend]. Exact use of OSPFv3 LSA + extensions is for further study. 4.5. RTM Capability Advertisement in IS-IS The capability to support RTM on a particular link (interface) is advertised in the GENINFO TLV described in [RFC6823] via the RTM Capability sub-TLV. With respect to the Flags field of the GENINFO TLV: o The S bit MUST be cleared to prevent the RTM Capability sub-TLV from leaking between levels. o The D bit of the Flags field MUST be cleared as required by [RFC6823]. o The I bit and the V bit MUST be set accordingly depending on whether RTM capability being advertised is for an IPv4 or an IPv6 interface. - Application ID (TBA4) will be assigned from the Application + Application ID (TBA3) will be assigned from the Application Identifiers for TLV 251 IANA registry. The RTM Capability sub-TLV MUST be included in GENINFO TLV in Application Specific Information. 4.6. RSVP-TE Control Plane Operation to Support RTM Throughout this document we refer to a node as RTM capable node when at least one of its interfaces is RTM capable. Figure 5 provides an example of roles a node may have with respect to RTM capability: ----- ----- ----- ----- ----- ----- ----- @@ -470,21 +469,21 @@ o G is a Boundary Clock with its ingress port in Slave state. Node G receives PTP messages. An ingress node that is configured to perform RTM along a path through an MPLS network to an egress node verifies that the selected egress node has an interface that supports RTM via the egress node's advertisement of the RTM Capability sub-TLV. In the Path message that the ingress node uses to instantiate the LSP to that egress node it places LSP_ATTRIBUTES Object [RFC5420] with RTM_SET Attribute Flag - set Section 8.8 which indicates to the egress node that RTM is + set Section 8.7 which indicates to the egress node that RTM is requested for this LSP. RTM_SET Attribute Flag SHOULD NOT be set in the LSP_REQUIRED_ATTRIBUTES object [RFC5420] , unless it is known that all nodes support RTM, because a node that does not recognize RTM_SET Attribute Flag would reject the Path message. If egress node receives Path message with RTM_SET Attribute Flag in LSP_ATTRIBUTES object, it MUST include initialized RRO [RFC3209] and LSP_ATTRIBUTES object where RTM_SET Attribute Flag is set and RTM_SET TLV Section 4.7 is initialized. When Resv message received by ingress node the RTM_SET TLV will contain an ordered list, from @@ -511,21 +510,21 @@ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |I| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Value ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: RTM_SET TLV format - Type value (TBA5) will be assigned by IANA from its Attributes TLV + Type value (TBA4) will be assigned by IANA from its Attributes TLV Space sub-registry. The Length contains the total length of the sub-object in bytes, including the Type and Length fields. The I bit flag indicates whether the downstream RTM capable node along the LSP is present in the RRO. Reserved field must be zeroed on initiation and ignored on receipt. @@ -533,24 +532,24 @@ TLVs. Only a single RTM_SET can be present in the LSP_ATTRIBUTES object. The sub-TLVs are defined in Section 4.7.1 below. The following processing procedures apply to every RTM capable node along the LSP that in this paragraph is referred as node for sake of brevity. Each node MUST examine Resv message whether RTM_SET Attribute Flag in the LSP_ATTRIBUTES object is set. If the RTM_SET flag set, the node MUST inspect the LSP_ATTRIBUTES object for presence of RTM_SET TLV. If more than one found, then the LSP setup MUST fail with generation of the ResvErr message with Error Code - Duplicate TLV Section 8.9 and Error Value that contains Type value in + Duplicate TLV Section 8.8 and Error Value that contains Type value in its 8 least significant bits. If no RTM_SET TLV has been found, then the LSP setup MUST fail with generation of the ResvErr message with - Error Code RTM_SET TLV Absent Section 8.9. If one RTM_SET TLV has + Error Code RTM_SET TLV Absent Section 8.8. If one RTM_SET TLV has been found the node will use the ID of the first node in the RTM_SET in conjunction with the RRO to compute the hop count to its downstream node with reachable RTM capable interface. If the node cannot find matching ID in RRO, then it MUST try to use ID of the next node in the RTM_SET until it finds the match or reaches the end of RTM_SET TLV. If match have been found, then the calculated value is used by the node as TTL value in outgoing label to reach the next RTM capable node on the LSP. Otherwise, the TTL value MUST be set to 255. The node MUST add RTM_SET sub-TLV with the same address it used in RRO sub-object at the beginning of the RTM_SET TLV in associated @@ -585,21 +584,21 @@ and Length fields. The Length MUST always be a multiple of 4, and at least 8 (smallest IPv4 sub-object). Sub-TLVs are organized as a last-in-first-out stack. The first -out sub-TLV relative to the beginning of RTM_SET TLV is considered the top. The last-out sub-TLV is considered the bottom. When a new sub- TLV is added, it is always added to the top. Only a single RTM_SET sub-TLV with the given Value field MUST be present in the RTM_SET TLV. If more than one sub-TLV is found the LSP setup MUST fail with the generation of a ResvErr message with the Error Code "Duplicate - sub-TLV" Section 8.9 and Error Value contains 16-bit value composed + sub-TLV" Section 8.8 and Error Value contains 16-bit value composed of (Type of TLV, Type of sub-TLV). Three kinds of sub-TLVs for RTM_SET are currently defined. 4.7.1.1. IPv4 Sub-TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -760,21 +759,21 @@ message will be forthcoming (this is necessary in order to Let any subsequent 2-step node know that there is already a follow-up message, and Let the end-point know to wait for a follow-up message; 2. Create a follow-up message in which to put the RTM determined as an initial correctionField value. - IEEE 1588v2 [IEEE.1588.2014] defines this behavior for PTP messages. + IEEE 1588v2 [IEEE.1588.2008] defines this behavior for PTP messages. Thus, for example, with reference to the PTP protocol, the PTPType field identifies whether the message is a Sync message, Follow_up message, Delay_Req message, or Delay_Resp message. The 10 octet long Port ID field contains the identity of the source port, that is, the specific PTP port of the boundary clock connected to the MPLS network. The Sequence ID is the sequence ID of the PTP message carried in the Value field of the message. PTP messages also include a bit that indicates whether or not a @@ -921,110 +920,96 @@ from OSPFv2 Extended Link TLV Sub-TLVs registry as follows: +-------+----------------+---------------+ | Value | Description | Reference | +-------+----------------+---------------+ | TBA2 | RTM Capability | This document | +-------+----------------+---------------+ Table 4: RTM Capability sub-TLV -8.5. RTM Capability sub-TLV in OSPFv3 - - IANA is requested to assign a new type for RTM Capability sub-TLV - from future OSPFv3 Extended-LSA Sub-TLVs registry that would be part - of OSPFv3 IANA registry as follows: - - +-------+----------------+---------------+ - | Value | Description | Reference | - +-------+----------------+---------------+ - | TBA3 | RTM Capability | This document | - +-------+----------------+---------------+ - - Table 5: RTM Capability sub-TLV - -8.6. IS-IS RTM Application ID +8.5. IS-IS RTM Application ID IANA is requested to assign a new Application ID for RTM from the Application Identifiers for TLV 251 registry as follows: +-------+-------------+---------------+ | Value | Description | Reference | +-------+-------------+---------------+ - | TBA4 | RTM | This document | + | TBA3 | RTM | This document | +-------+-------------+---------------+ - Table 6: IS-IS RTM Application ID + Table 5: IS-IS RTM Application ID -8.7. RTM_SET Sub-object RSVP Type and sub-TLVs +8.6. RTM_SET Sub-object RSVP Type and sub-TLVs IANA is requested to assign a new Type for RTM_SET sub-object from Attributes TLV Space sub-registry as follows: +-----+------------+-----------+---------------+---------+----------+ | Typ | Name | Allowed | Allowed on | Allowed | Referenc | | e | | on LSP_A | LSP_REQUIRED_ | on LSP | e | | | | TTRIBUTES | ATTRIBUTES | Hop Att | | | | | | | ributes | | +-----+------------+-----------+---------------+---------+----------+ | TBA | RTM_SET | Yes | No | No | This | - | 5 | sub-object | | | | document | + | 4 | sub-object | | | | document | +-----+------------+-----------+---------------+---------+----------+ - Table 7: RTM_SET Sub-object Type + Table 6: RTM_SET Sub-object Type IANA requested to create new sub-registry for sub-TLV types of RTM_SET sub-object as follows: +-----------+----------------------+-------------------------+ | Value | Description | Reference | +-----------+----------------------+-------------------------+ | 0 | Reserved | | | 1 | IPv4 address | This document | | 2 | IPv6 address | This document | | 3 | Unnumbered interface | This document | | 4-127 | Reserved | IETF Consensus | | 128 - 191 | Reserved | First Come First Served | | 192 - 255 | Reserved | Private Use | +-----------+----------------------+-------------------------+ - Table 8: RTM_SET object sub-object types + Table 7: RTM_SET object sub-object types -8.8. RTM_SET Attribute Flag +8.7. RTM_SET Attribute Flag IANA is requested to assign new flag from Attribute Flags registry +-----+--------+-----------+------------+-----+-----+---------------+ | Bit | Name | Attribute | Attribute | RRO | ERO | Reference | | No | | Flags | Flags Resv | | | | | | | Path | | | | | +-----+--------+-----------+------------+-----+-----+---------------+ | TBA | RTM_SE | Yes | Yes | No | No | This document | - | 6 | T | | | | | | + | 5 | T | | | | | | +-----+--------+-----------+------------+-----+-----+---------------+ - Table 9: RTM_SET Attribute Flag + Table 8: RTM_SET Attribute Flag -8.9. New Error Codes +8.8. New Error Codes IANA is requested to assign new Error Codes from Error Codes and Globally-Defined Error Value Sub-Codes registry +------------+--------------------+---------------+ | Error Code | Meaning | Reference | +------------+--------------------+---------------+ - | TBA7 | Duplicate TLV | This document | - | TBA8 | Duplicate sub-TLV | This document | - | TBA9 | RTM_SET TLV Absent | This document | + | TBA6 | Duplicate TLV | This document | + | TBA7 | Duplicate sub-TLV | This document | + | TBA8 | RTM_SET TLV Absent | This document | +------------+--------------------+---------------+ - Table 10: New Error Codes + Table 9: New Error Codes 9. Security Considerations Routers that support Residence Time Measurement are subject to the same security considerations as defined in [RFC5586] . In addition - particularly as applied to use related to PTP - there is a presumed trust model that depends on the existence of a trusted relationship of at least all PTP-aware nodes on the path traversed by PTP messages. This is necessary as these nodes are expected to @@ -1053,29 +1038,24 @@ 10. Acknowledgements Authors want to thank Loa Andersson, Lou Berger and Acee Lindem for their thorough reviews, thoughtful comments and, most of, patience. 11. References 11.1. Normative References - [I-D.ietf-ospf-ospfv3-lsa-extend] - Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3 - LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-09 - (work in progress), November 2015. - - [IEEE.1588.2014] + [IEEE.1588.2008] "Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", - IEEE Standard 1588, August 2014. + IEEE Standard 1588, July 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, . @@ -1122,20 +1102,25 @@ DOI 10.17487/RFC6823, December 2012, . [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 2015, . 11.2. Informative References + [I-D.ietf-ospf-ospfv3-lsa-extend] + Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3 + LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-10 + (work in progress), May 2016. + [I-D.ietf-tictoc-1588overmpls] Davari, S., Oren, A., Bhatia, M., Roberts, P., and L. Montini, "Transporting Timing messages over MPLS Networks", draft-ietf-tictoc-1588overmpls-07 (work in progress), October 2015. [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, .