From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7307.txt | 1123 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1123 insertions(+) create mode 100644 doc/rfc/rfc7307.txt (limited to 'doc/rfc/rfc7307.txt') diff --git a/doc/rfc/rfc7307.txt b/doc/rfc/rfc7307.txt new file mode 100644 index 0000000..ef4bcb2 --- /dev/null +++ b/doc/rfc/rfc7307.txt @@ -0,0 +1,1123 @@ + + + + + + +Internet Engineering Task Force (IETF) Q. Zhao +Request for Comments: 7307 Huawei Technology +Category: Standards Track K. Raza +ISSN: 2070-1721 C. Zhou + Cisco Systems + L. Fang + Microsoft + L. Li + China Mobile + D. King + Old Dog Consulting + July 2014 + + + LDP Extensions for Multi-Topology + +Abstract + + Multi-Topology (MT) routing is supported in IP networks with the use + of MT-aware IGPs. In order to provide MT routing within + Multiprotocol Label Switching (MPLS) Label Distribution Protocol + (LDP) networks, new extensions are required. + + This document describes the LDP protocol extensions required to + support MT routing in an MPLS environment. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7307. + + + + + + + + + + + + +Zhao, et al. Standards Track [Page 1] + +RFC 7307 LDP Multi-Topology Extensions July 2014 + + +Copyright Notice + + Copyright (c) 2014 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 + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zhao, et al. Standards Track [Page 2] + +RFC 7307 LDP Multi-Topology Extensions July 2014 + + +Table of Contents + + 1. Introduction ....................................................4 + 2. Terminology .....................................................4 + 3. Signaling Extensions ............................................5 + 3.1. Topology-Scoped Forwarding Equivalence Class (FEC) .........5 + 3.2. New Address Families: MT IP ................................5 + 3.3. LDP FEC Elements with MT IP AF .............................6 + 3.4. IGP MT-ID Mapping and Translation ..........................7 + 3.5. LDP MT Capability Advertisement ............................7 + 3.5.1. Protocol Extension ..................................7 + 3.5.2. Procedures ..........................................9 + 3.6. Label Spaces ..............................................10 + 3.7. Reserved MT-ID Values .....................................10 + 4. MT Applicability on FEC-Based Features .........................10 + 4.1. Typed Wildcard FEC Element ................................10 + 4.2. Signaling LDP Label Advertisement Completion ..............11 + 4.3. LSP Ping ..................................................11 + 4.3.1. New FEC Sub-Types ..................................11 + 4.3.2. MT LDP IPv4 FEC Sub-TLV ............................12 + 4.3.3. MT LDP IPv6 FEC Sub-TLV ............................13 + 4.3.4. Operation Considerations ...........................13 + 5. Error Handling .................................................14 + 5.1. MT Error Notification for Invalid Topology ID .............14 + 6. Backwards Compatibility ........................................14 + 7. MPLS Forwarding in MT ..........................................14 + 8. Security Considerations ........................................14 + 9. IANA Considerations ............................................15 + 10. Manageability Considerations ..................................17 + 10.1. Control of Function and Policy ...........................17 + 10.2. Information and Data Models ..............................17 + 10.3. Liveness Detection and Monitoring ........................17 + 10.4. Verify Correct Operations ................................17 + 10.5. Requirements on Other Protocols ..........................17 + 10.6. Impact on Network Operations .............................17 + 11. Contributors ..................................................18 + 12. Acknowledgements ..............................................19 + 13. References ....................................................19 + 13.1. Normative References .....................................19 + 13.2. Informative References ...................................19 + + + + + + + + + + + +Zhao, et al. Standards Track [Page 3] + +RFC 7307 LDP Multi-Topology Extensions July 2014 + + +1. Introduction + + Multi-Topology (MT) routing is supported in IP networks with the use + of MT-aware IGPs. It would be advantageous for Communications + Service Providers (CSPs) to support an MPLS Multi-Topology (MPLS-MT) + environment. The benefits of MPLS-MT technology are features for + various network scenarios, including: + + o A CSP may want to assign varying Quality of Service (QoS) profiles + to different traffic classes, based on a specific topology in an + MT routing network; + + o Separate routing and MPLS domains may be used to isolate multicast + and IPv6 islands within the backbone network; + + o Specific IP address space could be routed across an MT based on + security or operational isolation requirements; + + o Low-latency links could be assigned to an MT for delay-sensitive + traffic; + + o Management traffic may be divided from customer traffic using + different MTs utilizing separate links, thus ensuring that + management traffic is separated from customer traffic. + + This document describes the Label Distribution Protocol (LDP) + procedures and protocol extensions required to support MT routing in + an MPLS environment. + + This document defines two new Forwarding Equivalence Class (FEC) + types for use in Label Switched Path (LSP) ping [RFC4379]. + +2. Terminology + + This document uses MPLS terminology defined in [RFC5036]. Additional + terms are defined below: + + o MT-ID: A 16-bit value used to represent the Multi-Topology ID. + + o Default MT Topology: A topology that is built using the MT-ID + default value of 0. + + o MT Topology: A topology that is built using the corresponding MT- + ID. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + + + +Zhao, et al. Standards Track [Page 4] + +RFC 7307 LDP Multi-Topology Extensions July 2014 + + +3. Signaling Extensions + +3.1. Topology-Scoped Forwarding Equivalence Class (FEC) + + LDP assigns and binds a label to a FEC, where a FEC is a list of one + or more FEC elements. To set up LSPs for unicast IP routing paths, + LDP assigns local labels for IP prefixes and advertises these labels + to its peers so that an LSP is set up along the routing path. To set + up MT LSPs for IP prefixes under a given topology scope, the LDP + prefix-related FEC element must be extended to include topology + information. This implies that the MT-ID becomes an attribute of the + prefix-related FEC element, and all FEC-Label binding operations are + performed under the context of a given topology (MT-ID). + + The following section ("New Address Families: MT IP") defines the + extension required to bind the prefix-related FEC to a topology. + +3.2. New Address Families: MT IP + + Section 2.1 of the LDP base specification [RFC5036] defines the + Address Prefix FEC element. The Prefix encoding is defined for a + given "Address Family" (AF), and has length (in bits) specified by + the "PreLen" field. + + To extend IP address families for MT, two new Address Families named + "MT IP" and "MT IPv6" are used to specify IPv4 and IPv6 prefixes + within a topology scope. + + The format of data associated with these new Address Families is + described below: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IPv4 Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | MT-ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 1: MT IP Address Family Format + + + + + + + + + + + +Zhao, et al. Standards Track [Page 5] + +RFC 7307 LDP Multi-Topology Extensions July 2014 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IPv6 Address | + | | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | MT-ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 2: MT IPv6 Address Family Format + + Where "IP Address" is an IPv4 and IPv6 address/prefix for "MT IP" and + "MT IPv6" AF respectively, and the field "MT-ID" corresponds to the + 16-bit Topology ID for a given address. + + The definition and usage for the remaining fields in the FEC elements + are as defined for IP/IPv6 AF. The value of MT-ID 0 corresponds to + the default topology and MUST be ignored on receipt so as to not + cause any conflict/confusion with existing non-MT procedures. + + The defined FEC elements with "MT IP" Address Family can be used in + any LDP message and procedures that currently specify and allow the + use of FEC elements with IP/IPv6 Address Family. + +3.3. LDP FEC Elements with MT IP AF + + The following section specifies the format extensions of the existing + LDP FEC elements to support MT. The "Address Family" of these FEC + elements will be set to "MT IP" or "MT IPv6". + + The MT Prefix FEC element encoding is as follows: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Prefix (2) | Address Family (MT IP/MT IPv6)| PreLen | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Prefix | + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | MT-ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 3: MT Prefix FEC Element Format + + + + + +Zhao, et al. Standards Track [Page 6] + +RFC 7307 LDP Multi-Topology Extensions July 2014 + + + The MT Typed Wildcard FEC element encoding is as follows: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |Typed Wcard (5)| FEC Type | Len = 6 | AF = MT IP ..| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |... or MT IPv6 | MT-ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 4: MT Typed Wildcard FEC Element + + The above format can be used for any LDP FEC element that allows use + of the IP/IPv6 Address Family. In the scope of this document, the + allowed "FEC Type" in a MT Typed Wildcard FEC element is the Prefix + FEC element. + +3.4. IGP MT-ID Mapping and Translation + + The non-reserved non-special IGP MT-ID values can be used and carried + in LDP without the need for translation. However, there is a need + for translating reserved or special IGP MT-ID values to corresponding + LDP MT-IDs. The assigned, unassigned, and special LDP MT-ID values + have been assigned as described in Section 9 ("IANA Considerations"). + + How future LDP MT-ID values are allocated is outside the scope of + this document. Instead, a separate document will be created to + detail the allocation policy and process for requesting new MT-ID + values. + +3.5. LDP MT Capability Advertisement + +3.5.1. Protocol Extension + + We specify a new LDP capability, named "Multi-Topology (MT)", which + is defined in accordance with the LDP capability guidelines + [RFC5561]. The LDP "MT" capability can be advertised by an LDP + speaker to its peers either during the LDP session initialization or + after the LDP session is set up. The advertisement is to announce + the capability of the Label Switching Router (LSR) to support MT for + the given IP address family. An LDP speaker MUST NOT send messages + containing MT FEC elements unless the peer has said it can handle it. + + The MT capability is specified using the Multi-Topology Capability + TLV. The Multi-Topology Capability TLV format is in accordance with + the LDP capability guidelines as defined in [RFC5561]. To be able to + + + + + +Zhao, et al. Standards Track [Page 7] + +RFC 7307 LDP Multi-Topology Extensions July 2014 + + + specify IP address family, the capability-specific data (i.e., the + "Capability Data" field of Capability TLV) is populated using the + "Typed Wildcard FEC element" as defined in [RFC5918]. + + The format of the Multi-Topology Capability TLV is as follows: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |U|F| Multi-Topology Cap.(IANA) | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |S| Reserved | | + +-+-+-+-+-+-+-+-+ | + ~ Typed Wildcard FEC element(s) ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 5: Multi-Topology Capability TLV Format + + Where: + + o U-bit: MUST be 1 so that the TLV will be silently ignored by a + recipient if it is unknown, according to the rules of [RFC5036]. + + o F-bit: MUST be 0 as per Section 3 ("Specifying Capabilities in LDP + Messages") of LDP Capabilities [RFC5561]. + + o Multi-Topology Capability: Capability TLV type (IANA assigned) + + o S-bit: MUST be 1 if used in LDP "Initialization" message. MAY be + set to 0 or 1 in dynamic "Capability" message to advertise or + withdraw the capability, respectively. + + o Typed Wildcard FEC element(s): One or more elements specified as + the "Capability data". + + o Length: length of Value field, starting from the S-bit, in octets. + + o The encoding of the Typed Wildcard FEC element, as defined in + [RFC5918], is defined in Section 4.1 ("Typed Wildcard FEC + element") of this document. The MT-ID field of the MT Typed + Wildcard FEC element MUST be set to "Wildcard Topology" when it is + specified in the MT Capability TLV. + + + + + + + + +Zhao, et al. Standards Track [Page 8] + +RFC 7307 LDP Multi-Topology Extensions July 2014 + + +3.5.2. Procedures + + To announce its MT capability for an IP address family, LDP FEC type, + and Multi-Topology, an LDP speaker sends an "MT Capability" including + the exact Typed Wildcard FEC element with the corresponding + "AddressFamily" field (i.e., set to "MT IP" for IPv4 and set to "MT + IPv6" for IPv6 address family), corresponding "FEC Type" field (i.e., + set to "Prefix"), and corresponding "MT-ID". To announce its MT + capability for both the IPv4 and IPv6 address family, or for multiple + FEC types, or for multiple Multi-Topologies, an LDP speaker sends an + "MT Capability" with one or more MT Typed FEC elements in it. + + o The capability for supporting multi-topology in LDP can be + advertised during LDP session initialization stage by including + the LDP MT capability TLV in LDP Initialization message. After an + LDP session is established, the MT capability can also be + advertised or withdrawn using the Capability message (only if the + "Dynamic Capability Announcement" capability [RFC5561] has already + been successfully negotiated). + + o If an LSR has not advertised MT capability, its peer MUST NOT send + to this LSR any LDP messages with FEC elements that include an MT + identifier. + + o If an LSR is changed from non-MT capable to MT capable, it sets + the S-bit in the MT capability TLV and advertises via the + Capability message (if it supports Dynamic Capability + Announcement). The existing LSP is treated as an LSP for default + MT (ID 0). + + o If an LSR is changed from LDP-MT capable to non-MT capable, it + initiates withdrawal of all label mapping for existing LSPs of all + non-default MTs. It also cleans up all the LSPs of all non- + default MTs locally. Then, it clears the S-bit in the MT + capability TLV and advertises via the Capability message (if it + supports Dynamic Capability Announcement). When an LSR knows the + peer node is changed from LDP-MT capable to non-MT capable, it + cleans up all the LSPs of all non-default MTs locally and + initiates withdrawal of all label mapping for existing LSPs of all + non-default MTs. Each side of the node sends a label release to + its peer once it receives the label release messages even though + each side has already cleaned up all the LSPs locally. + + o If an LSR does not support "Dynamic Capability Announcement", it + MUST reset the session with its peer whenever the LSR changes its + local capability with regards to supporting LDP MT. + + + + + +Zhao, et al. Standards Track [Page 9] + +RFC 7307 LDP Multi-Topology Extensions July 2014 + + + o If an LSR is changed from IGP-MT capable to non-MT capable, it may + wait until the routes update to withdraw the FEC and release the + label mapping for existing LSPs of a specific MT. + +3.6. Label Spaces + + The use of multiple topologies for LDP does not require different + label spaces for each topology. An LSR can use the same label space + for all MT FECs as for the default topology. + + Similarly, signaling for different topologies can and should be done + within a single LDP session. + +3.7. Reserved MT-ID Values + + Certain MT topologies are assigned to serve predetermined purposes. + + In Section 9 ("IANA Considerations"), this document defines a new + IANA registry "MPLS Multi-Topology Identifiers" to keep LDP MT-ID + reserved values. + + If an LSR receives a FEC element with an "MT-ID" value that is + "Unassigned" for future use (and not IANA allocated yet), the LSR + MUST abort the processing of the FEC element and SHOULD send a + notification message with status code "Invalid Topology ID" to the + sender. + +4. MT Applicability on FEC-Based Features + +4.1. Typed Wildcard FEC Element + + [RFC5918] extends base LDP and defines the Typed Wildcard FEC element + framework. The Typed Wildcard FEC element can be used in any LDP + message to specify a wildcard operation/action for a given type of + FEC. + + The MT extensions defined in this document do not require any + extension to procedures for the Typed Wildcard FEC element, and these + procedures apply as is to MT wildcarding. The MT extensions, though, + allow use of "MT IP" or "MT IPv6" in the Address Family field of the + Typed Wildcard FEC element in order to use wildcard operations in the + context of a given topology. The use of MT-scoped address family + also allows us to specify MT-ID in these operations. + + The defined format in Section 4.1 ("Typed Wildcard FEC element") + allows an LSR to perform wildcard FEC operations under the scope of a + topology. If an LSR wishes to perform a wildcard operation that + applies to all topologies, it can use a "Wildcard Topology" MT-ID. + + + +Zhao, et al. Standards Track [Page 10] + +RFC 7307 LDP Multi-Topology Extensions July 2014 + + + For example, upon local de-configuration of a topology "x", an LSR + may send a typed wildcard Label Withdraw message with MT-ID "x" to + withdraw all its labels from the peer that advertised under the scope + of topology "x". Additionally, upon a global configuration change, + an LSR may send a typed wildcard Label Withdraw message with the + MT-ID set to "Wildcard Topology" to withdraw all its labels under all + topologies from the peer. + +4.2. Signaling LDP Label Advertisement Completion + + [RFC5919] specifies extensions and procedures for an LDP speaker to + signal its convergence for a given FEC type towards a peer. The + procedures defined in [RFC5919] apply as they are to an MT FEC + element. This allows an LDP speaker to signal its IP convergence + using Typed Wildcard FEC element, and its MT IP convergence per + topology using a MT Typed Wildcard FEC element. + +4.3. LSP Ping + + [RFC4379] defines procedures to detect data-plane failures in MPLS + LSPs via LSP ping. That specification defines a "Target FEC Stack" + TLV that describes the FEC stack being tested. This TLV is sent in + an MPLS Echo Request message towards the LSP's egress LSR and is + forwarded along the same data path as other packets belonging to the + FEC. + + "Target FEC Stack" TLV contains one or more sub-TLVs pertaining to + different FEC types. Section 3.2 of [RFC4379] defines the Sub-Types + and format of the FEC. To support LSP ping for MT LDP LSPs, this + document defines the following extensions to [RFC4379]. + +4.3.1. New FEC Sub-Types + + We define two new FEC types for LSP ping: + + o MT LDP IPv4 FEC + + o MT LDP IPv6 FEC + + We also define the following new sub-types for sub-TLVs to specify + these FECs in the "Target FEC Stack" TLV of [RFC4379]: + + Sub-Type Length Value Field + -------- ------ ----------------- + 31 8 MT LDP IPv4 prefix + 32 20 MT LDP IPv6 prefix + + Figure 6: New Sub-Types for Sub-TLVs + + + +Zhao, et al. Standards Track [Page 11] + +RFC 7307 LDP Multi-Topology Extensions July 2014 + + + The rules and procedures of using these sub-TLVs in an MPLS echo + request message are the same as defined for LDP IPv4/IPv6 FEC sub-TLV + types in [RFC4379]. + +4.3.2. MT LDP IPv4 FEC Sub-TLV + + The format of the "MT LDP IPv4 FEC" sub-TLV to be used in a "Target + FEC Stack" [RFC4379] is: + + 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 = 31 (MT LDP IPv4 FEC) | Length = 8 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IPv4 prefix | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Prefix Length | MBZ | MT-ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 7: MT LDP IPv4 FEC Sub-TLV + + The format of this sub-TLV is similar to the LDP IPv4 FEC sub-TLV as + defined in [RFC4379]. In addition to "IPv4 prefix" and "Prefix + Length" fields, this new sub-TLV also specifies the MT-ID (Multi- + Topology ID). The Length for this sub-TLV is 5. + + The term "Must Be Zero" (MBZ) is used in object descriptions for + reserved fields. These fields MUST be set to zero when sent and + ignored on receipt. + + + + + + + + + + + + + + + + + + + + + + +Zhao, et al. Standards Track [Page 12] + +RFC 7307 LDP Multi-Topology Extensions July 2014 + + +4.3.3. MT LDP IPv6 FEC Sub-TLV + + The format of the "MT LDP IPv6 FEC" sub-TLV to be used in a "Target + FEC Stack" [RFC4379] is: + + 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 = 32 (MT LDP IPv6 FEC) | Length = 20 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | IPv6 prefix | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Prefix Length | MBZ | MT-ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 8: MT LDP IPv6 FEC Sub-TLV + + The format of this sub-TLV is similar to the LDP IPv6 FEC sub-TLV as + defined in [RFC4379]. In addition to the "IPv6 prefix" and "Prefix + Length" fields, this new sub-TLV also specifies the MT-ID (Multi- + Topology ID). The Length for this sub-TLV is 17. + +4.3.4. Operation Considerations + + To detect data-plane failures using LSP ping for a specific topology, + the router will initiate an LSP ping request with the target FEC + stack TLV containing the LDP MT IP Prefix Sub-TLV in the Echo Request + packet. The Echo Request packet is sent with the label bound to the + IP Prefix in the topology. Once the Echo Request packet reaches the + target router, it will process the packet and perform checks for the + LDP MT IP Prefix sub-TLV present in the Target FEC Stack as described + in [RFC4379] and respond according to the processing rules in + [RFC4379]. For the case that the LSP ping with return path is not + specified, the reply packet must go through the default topology + instead of the topology where the Echo Request goes through. + + It should be noted that the existing MIB modules for an MPLS LSR + [RFC3813] and MPLS LDP managed objects [RFC3815] do not provide the + necessary information to support the extensions in this document. + For example, the absence of the MT-ID as an index into the MIB + modules means that there is no way to disambiguate different topology + instances. + + + + + + +Zhao, et al. Standards Track [Page 13] + +RFC 7307 LDP Multi-Topology Extensions July 2014 + + +5. Error Handling + + The extensions defined in this document utilize the existing LDP + error handling defined in [RFC5036]. If an LSR receives an error + notification from a peer for a session, it terminates the LDP session + by closing the TCP transport connection for the session and + discarding all multi-topology label mappings learned via the session. + +5.1. MT Error Notification for Invalid Topology ID + + An LSR should respond with an "Invalid Topology ID" status code in + the LDP Notification message when it receives an LDP message with a + FEC element specifying an MT-ID that is not locally known or not + supported. The LSR MUST also discard the entire message before + sending the Notification message. + +6. Backwards Compatibility + + The MPLS-MT solution is backwards compatible with existing LDP + enhancements defined in [RFC5036], including message authenticity, + integrity of message, and topology loop detection. + + The legacy node that does not support MT should not receive any + MT-related LDP messages. In case bad things happen, according to + [RFC5036], processing of such messages should be aborted. + +7. MPLS Forwarding in MT + + Although forwarding is out of the scope of this document, we include + some forwarding consideration for informational purposes here. + + The specified signaling mechanisms allow all the topologies to share + the platform-specific label space. This feature allows the existing + data-plane techniques to be used. Also, there is no way for the data + plane to associate a received packet with any one topology, meaning + that topology-specific label spaces cannot be used. + +8. Security Considerations + + The use of MT over existing MPLS solutions does not offer any + specific security benefit. + + General LDP communication security threats and how these may be + mitigated are described in [RFC5036]; these threats include: + + o spoofing + + o privacy + + + +Zhao, et al. Standards Track [Page 14] + +RFC 7307 LDP Multi-Topology Extensions July 2014 + + + o denial of service + + For further discussion regarding possible LDP communication threats + and mitigation techniques, see [RFC5920]. + +9. IANA Considerations + + This document introduces the following new protocol elements, which + have been assigned by IANA: + + o New LDP Capability TLV: "Multi-Topology Capability" TLV (0x050C) + from the LDP Parameters registry "TLV Type Name Space". + + o New Status Code: "Invalid Topology ID" (0x00000031) from the LDP + Parameters registry "Status Code Name Space"). + + Registry: + Range/Value Description + -------------- ------------------------------ + 0x00000031 Invalid Topology ID + + Figure 9: New Code Point for LDP Multi-Topology Extensions + + o New address families under the IANA registry "Address Family + Numbers": + + Number Description + -------- ------------------------------------ + 29 MT IP: Multi-Topology IP version 4 + 30 MT IPv6: Multi-Topology IP version 6 + + Figure 10: Address Family Numbers + + + + + + + + + + + + + + + + + + + +Zhao, et al. Standards Track [Page 15] + +RFC 7307 LDP Multi-Topology Extensions July 2014 + + + o New registry "MPLS Multi-Topology Identifiers". + + This is a registry of the "Multiprotocol Label Switching + Architecture (MPLS)" category. + + The initial registrations and allocation policies for this + registry are: + + Range/Value Purpose Reference + ----------- ------------------------------------- ---------- + 0 Default/standard topology RFC 7307 + 1 IPv4 in-band management RFC 7307 + 2 IPv6 routing topology RFC 7307 + 3 IPv4 multicast topology RFC 7307 + 4 IPv6 multicast topology RFC 7307 + 5 IPv6 in-band management RFC 7307 + 6-3995 Unassigned for future IGP topologies RFC 7307 + Assigned by Standards Action RFC 7307 + 3996-4095 Experimental RFC 7307 + 4096-65534 Unassigned for MPLS topologies RFC 7307 + Assigned by Standards Action + 65535 Wildcard Topology RFC 7307 + + Figure 11: MPLS Multi-Topology Identifier Registry + + o New Sub-TLV Types for LSP ping: The following new sub-type values + under TLV type 1 (Target FEC Stack) have been registered from the + "Sub-TLVs for TLV Types 1, 16, and 21" sub-registry within the + "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) + Ping Parameters" registry. + + Sub-Type Value Field + -------- ------------------ + 31 MT LDP IPv4 prefix + 32 MT LDP IPv6 prefix + + Figure 12: New Sub-TLV Types for LSP Ping + + As highlighted at the end of Section 3.4 ("IGP MT-ID Mapping and + Translation"), a new document will be created to detail the policy + and process for allocating new MT-ID values. + + + + + + + + + + +Zhao, et al. Standards Track [Page 16] + +RFC 7307 LDP Multi-Topology Extensions July 2014 + + +10. Manageability Considerations + +10.1. Control of Function and Policy + + There are capabilities that should be configurable to enable good + manageability. One such example is to allow that the LDP Multi- + Topology capability be enabled or disabled. It is assumed that the + mapping of the LDP MT-ID and IGP MT-ID is manually configured on + every router by default. If an automatic mapping between IGP MT-IDs + and LDP MT-IDs is needed, there must be explicit configuration to do + so. + +10.2. Information and Data Models + + Any extensions that may be required for existing MIBs are beyond the + scope of this document. + +10.3. Liveness Detection and Monitoring + + Mechanisms defined in this document do not imply any new liveness + detection and monitoring requirements. + +10.4. Verify Correct Operations + + In order to debug an LDP-MT-enabled network, it may be necessary to + associate between the LDP label advertisement and the IGP routing + advertisement. In this case, the user MUST understand the mapping + mechanism to convert the IGP MT-ID to the LDP MT-ID. The method and + type of mapping mechanism is out of the scope of this document. + +10.5. Requirements on Other Protocols + + If the LDP MT-ID has an implicit dependency on IGP MT-ID, then the + corresponding IGP MT features will need to be supported. + +10.6. Impact on Network Operations + + Mechanisms defined in this document do not have any impact on network + operations. + + + + + + + + + + + + +Zhao, et al. Standards Track [Page 17] + +RFC 7307 LDP Multi-Topology Extensions July 2014 + + +11. Contributors + + Ning So + Tata Communications + 2613 Fairbourne Cir. + Plano, TX 75082 + USA + + EMail: ning.so@tatacommunications.com + + + Raveendra Torvi + Juniper Networks + 10 Technology Park Drive + Westford, MA 01886-3140 + US + + EMail: rtorvi@juniper.net + + + Huaimo Chen + Huawei Technology + 125 Nagog Technology Park + Acton, MA 01719 + US + + Emily Chen + 2717 Seville Blvd, Apt. 1205 + Clearwater, FL 33764 + US + + EMail: emily.chen220@gmail.com + + + Chen Li + China Mobile + 53A, Xibianmennei Ave. + Xunwu District, Beijing 01719 + China + + EMail: lichenyj@chinamobile.com + + + Lu Huang + China Mobile + 53A, Xibianmennei Ave. + Xunwu District, Beijing 01719 + China + + + +Zhao, et al. Standards Track [Page 18] + +RFC 7307 LDP Multi-Topology Extensions July 2014 + + +12. Acknowledgements + + The authors would like to thank Dan Tappan, Nabil Bitar, Huang Xin, + Eric Rosen, IJsbrand Wijnands, Dimitri Papadimitriou, Yiqun Chai, + Pranjal Dutta, George Swallow, Curtis Villamizar, Adrian Farrel, Alia + Atlas, and Loa Anderson for their valuable comments on this document. + +13. References + +13.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol + Label Switched (MPLS) Data Plane Failures", RFC 4379, + February 2006. + + [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., + "LDP Specification", RFC 5036, October 2007. + + [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. + Le Roux, "LDP Capabilities", RFC 5561, July 2009. + + [RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution + Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class + (FEC)", RFC 5918, August 2010. + + [RFC5919] Asati, R., Mohapatra, P., Chen, E., and B. Thomas, + "Signaling LDP Label Advertisement Completion", RFC 5919, + August 2010. + +13.2. Informative References + + [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS + Networks", RFC 5920, July 2010. + + [RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, + "Multiprotocol Label Switching (MPLS) Label Switching + Router (LSR) Management Information Base (MIB)", RFC 3813, + June 2004. Srinivasan, C., Viswanathan, A., and T. + Nadeau, + + [RFC3815] Cucchiara, J., Sjostrand, H., and J. Luciani, "Definitions + of Managed Objects for the Multiprotocol Label Switching + (MPLS), Label Distribution Protocol (LDP)", RFC 3815, June + 2004. + + + + +Zhao, et al. Standards Track [Page 19] + +RFC 7307 LDP Multi-Topology Extensions July 2014 + + +Authors' Addresses + + Quintin Zhao + Huawei Technology + 125 Nagog Technology Park + Acton, MA 01719 + US + EMail: quintin.zhao@huawei.com + + + Kamran Raza + Cisco Systems + 2000 Innovation Drive + Kanata, ON K2K-3E8 + Canada + EMail: skraza@cisco.com + + + Chao Zhou + Cisco Systems + 300 Beaver Brook Road + Boxborough, MA 01719 + US + EMail: czhou@cisco.com + + + Luyuan Fang + Microsoft + 5600 148th Ave NE + Redmond, WA 98052 + US + EMail: lufang@microsoft.com + + + Lianyuan Li + China Mobile + 53A, Xibianmennei Ave. + Xunwu District, Beijing 01719 + China + EMail: lilianyuan@chinamobile.com + + + Daniel King + Old Dog Consulting + EMail: daniel@olddog.co.uk + + + + + + +Zhao, et al. Standards Track [Page 20] + -- cgit v1.2.3