summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7307.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7307.txt')
-rw-r--r--doc/rfc/rfc7307.txt1123
1 files changed, 1123 insertions, 0 deletions
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]
+