GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7307

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]

/home/gen.uk/domains/wiki.gen.uk/public_html/data/pages/rfc/rfc7307.txt · Last modified: 2014/07/22 18:38 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki