Internet Engineering Task Force (IETF)                           Q. Zhao
Internet-Draft
Request for Comments: 7307                             Huawei Technology
Intended status:
Category: Standards Track                                        K. Raza
Expires: October 31, 2014
ISSN: 2070-1721                                                  C. Zhou
                                                           Cisco Systems
                                                                 L. Fang
                                                               Microsoft
                                                                   L. Li
                                                            China Mobile
                                                                 D. King
                                                      Old Dog Consulting
                                                          April 23,
                                                               July 2014

                   LDP Extensions for Multi Topology
               draft-ietf-mpls-ldp-multi-topology-12.txt Multi-Topology

Abstract

   Multi-Topology (MT) routing is supported in IP networks with the use
   of MT aware MT-aware IGPs.  In order to provide MT routing within
   Multiprotocol Label Switching (MPLS) Label Distribution Protocol
   (LDP) networks networks, new extensions are required.

   This document describes the LDP protocol extensions required to
   support MT routing in an MPLS environment.

Status of this This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for a maximum publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of six months RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on October 31, 2014.
   http://www.rfc-editor.org/info/rfc7307.

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.

Table of Contents

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4 ....................................................4
   2. Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4 .....................................................4
   3. Signaling Extensions . . . . . . . . . . . . . . . . . . . . .  5 ............................................5
      3.1. Topology-Scoped Forwarding Equivalence Class (FEC) . . . .  5 .........5
      3.2. New Address Families: MT IP  . . . . . . . . . . . . . . .  5 ................................5
      3.3. LDP FEC Elements with MT IP AF . . . . . . . . . . . . . .  6 .............................6
      3.4. IGP MT-ID Mapping and Translation  . . . . . . . . . . . .  7 ..........................7
      3.5. LDP MT Capability Advertisement  . . . . . . . . . . . . .  7 ............................7
           3.5.1. Protocol Extension . . . . . . . . . . . . . . . . . .  7 ..................................7
           3.5.2. Procedures . . . . . . . . . . . . . . . . . . . . . .  8 ..........................................9
      3.6. Label Spaces . . . . . . . . . . . . . . . . . . . . . . . 10 ..............................................10
      3.7. Reserved MT ID MT-ID Values  . . . . . . . . . . . . . . . . . . 10 .....................................10
   4. MT Applicability on FEC-based features . . . . . . . . . . . . 10 FEC-Based Features .........................10
      4.1. Typed Wildcard FEC Element . . . . . . . . . . . . . . . . 10 ................................10
      4.2.  End-of-LIB . . . . . . . . . . . . . . . . . . . . . . . . 11 Signaling LDP Label Advertisement Completion ..............11
      4.3. LSP Ping . . . . . . . . . . . . . . . . . . . . . . . . . 11 ..................................................11
           4.3.1. New FEC Sub-Types  . . . . . . . . . . . . . . . . . . 11 ..................................11
           4.3.2. MT LDP IPv4 FEC Sub-TLV  . . . . . . . . . . . . . . . 12 ............................12
           4.3.3. MT LDP IPv6 FEC Sub-TLV  . . . . . . . . . . . . . . . 12 ............................13
           4.3.4. Operation Considerations . . . . . . . . . . . . . . . 13 ...........................13
   5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 13 .................................................14
      5.1. MT Error Notification for Invalid Topology ID  . . . . . . 13 .............14
   6. Backwards Compatibility  . . . . . . . . . . . . . . . . . . . 13 ........................................14
   7. MPLS Forwarding in MT  . . . . . . . . . . . . . . . . . . . . 14 ..........................................14
   8. Security Consideration . . . . . . . . . . . . . . . . . . . . 14 Considerations ........................................14
   9. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14 ............................................15
   10. Manageability Considerations . . . . . . . . . . . . . . . . . 16 ..................................17
      10.1. Control of Function and Policy . . . . . . . . . . . . . . 16 ...........................17
      10.2. Information and Data Models  . . . . . . . . . . . . . . . 16 ..............................17
      10.3. Liveness Detection and Monitoring  . . . . . . . . . . . . 16 ........................17
      10.4. Verify Correct Operations  . . . . . . . . . . . . . . . . 16 ................................17
      10.5. Requirements On on Other Protocols  . . . . . . . . . . . . . 16 ..........................17
      10.6. Impact On on Network Operations . . . . . . . . . . . . . . . 17 .............................17
   11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17 ..................................................18
   12. Acknowledgement  . . . . . . . . . . . . . . . . . . . . . . . 18 Acknowledgements ..............................................19
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 ....................................................19
      13.1. Normative References . . . . . . . . . . . . . . . . . . . 18 .....................................19
      13.2. Informative References . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 ...................................19

1.  Introduction

   Multi-Topology (MT) routing is supported in IP networks with the use
   of MT aware MT-aware IGPs.  It would be advantageous for Communications
   Service Providers (CSP) (CSPs) to support Multiple Topologies (MT) within an MPLS environments (MPLS-MT). Multi-Topology (MPLS-MT)
   environment.  The benefits of MPLS-MT technology provide are features for
   various network scenarios, including:

   o  A CSP may want to assign varying Quality of Service (QoS) profiles
      to different traffic classes. 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  Low-latency links could be assigned to an MT for delay sensitive 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 also updates RFC4379 by defining defines two new Forwarding Equivalence Class (FEC)
   types for use in Label Switched Path (LSP) ping. ping [RFC4379].

2.  Terminology

   This document uses MPLS terminology defined in [RFC5036].  Additional
   terms are defined below:

   o  MT-ID: A 16 bit 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. 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].

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 setup set up LSPs for unicast IP routing paths,
   LDP assigns local labels for IP prefixes, prefixes and advertises these labels
   to its peers so that an LSP is setup set up along the routing path.  To setup set
   up MT LSPs for IP prefixes under a given topology scope, the LDP "prefix-related"
   prefix-related FEC element must be extended to include topology
   information.  This implies that the MT-ID becomes an attribute of Prefix-related the
   prefix-related FEC element, and all FEC-Label binding operations are
   performed under the context of a given topology (MT-ID).

   The following subsection 3.2 (New section ("New Address Families (AF): Families: MT IP) IP") defines the
   extension required to bind "prefix-related" the prefix-related FEC to a topology.

3.2.  New Address Families: MT IP

   The

   Section 2.1 of the LDP base specification [RFC5036] (Section 2.1) defines the
   "Prefix"
   Address Prefix FEC Element. element.  The "Prefix" 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
    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 16-
   bit the
   16-bit Topology ID for a given address.

   The definition and usage for the remaining fields in the FEC Elements 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 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 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 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
   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         MT-ID                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 4: MT Typed Wildcard FEC Element

   The above format can be used for any LDP FEC Element element that allows use
   of the IP/IPv6 address family. Address Family.  In the scope of this document, the
   allowed "FEC Type" in a MT Typed Wildcard FEC Element element is "Prefix" 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 unassigned, and special LDP MT-ID values
   are requested In
   have been assigned as described in Section 9.  (IANA Considerations). 9 ("IANA Considerations").

   How future LDP MT-ID values are allocated are out of of is outside the scope of
   this document.  Instead  Instead, a new Internet-Draft separate document will be created to document
   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 definition 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 setup set up.  The advertisement is to announce LSR
   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 "Multi-Topology Capability" the Multi-Topology Capability
   TLV.  The "Multi-Topology Capability" Multi-Topology Capability TLV format is in accordance with
   the LDP capability guidelines as defined in [RFC5561].  To be able to
   specify IP address family, the capability specific capability-specific data (i.e. (i.e., the
   "Capability Data" field of Capability TLV) is populated using the
   "Typed Wildcard FEC
   Element" element" as defined in [RFC5918].

   The format of "Multi-Topology Capability" 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 unkown unknown, according to the rules of [RFC5036].

   o  F-bit: MUST be 0 as per Section 3 (Specifying ("Specifying Capabilities in LDP
      Messages)
      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 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 S bit, the S-bit, in octets.

   o  The encoding of the Typed Wildcard FEC element, as defined in
      [RFC5918], is defined in the section 3.3 (Typed Section 4.1 ("Typed Wildcard FEC
      Element)
      element") of this document.  The MT-ID field of the MT Typed
      Wildcard FEC Element element MUST be set to "Wildcard Topology" when it is
      specified in the MT Capability TLV.

3.5.2.  Procedures

   To announce its MT capability for an IP address family, LDP FEC type,
   and Multi Topology, 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, 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 to
      this LSR.
      identifier.

   o  If an LSR is changed from non-MT capable to MT capable, it sets
      the S bit S-bit in the MT capability TLV and advertises via the
      Capability message (if it supports Dynamic Announcement Capability). 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 withdraw 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  Then, it clears the S bit S-bit in the MT
      capability TLV and advertises via the Capability message (if it
      supports Dynamic Announcement Capability). Capability Announcement).  When an LSR knows the
      peer node is changed from LDP-MT capable to non-MT capable, it cleanup
      cleans up all the LSPs of all non-default MTs locally and initiate withdraw
      initiates withdrawal of all label mapping for existing LSPs of all
      non-default MTs.  Both
      sides  Each side of the nodes send node sends a label release to
      its peer once they
      receive it receives the label release messages even both sides have though
      each side has already cleaned up all the LSPs locally.

   o  If an LSR does not support "Dynamic Announcement Capability", Capability Announcement", it
      MUST reset the session with its peer whenever the LSR changes its
      local capability with regards to supporting LDP MT.

   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 MT-ID Values

   Certain MT topologies are assigned to serve predetermined purposes.

   In Section 9.  (IANA Considerations), 9 ("IANA Considerations"), this document defines a new
   IANA registry "LDP "MPLS Multi-Topology ID Name Space" under IANA "LDP
   Parameter" namespace Identifiers" to keep an LDP MT-ID
   reserved value. values.

   If an LSR receives a FEC element with an "MT-ID" value that is
   "Reserved"
   "Unassigned" for future use (and not IANA allocated yet), the LSR
   MUST abort the processing of the FEC element, element and SHOULD send a
   notification message with status code "Invalid Topology ID" to the
   sender.

4.  MT Applicability on FEC-based features FEC-Based Features

4.1.  Typed Wildcard FEC Element

   [RFC5918] extends base LDP and defines the Typed Wildcard FEC Element 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 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 3.3 (Typed 4.1 ("Typed Wildcard FEC Element) 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.

   For example, upon local de-configuration of a topology "x", an LSR
   may send a typed wildcard label withdraw 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 Label Withdraw message with the
   MT-ID set to "Wildcard Topology" to withdraw all its labels under all
   topologies from the peer.

4.2.  End-of-LIB  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] applies as-is 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 Echo Request message towards LSPs the LSP's egress LSR, 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 for 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
         --------       ------            -----------------
             TBA1
               31            8            MT LDP IPv4 prefix
             TBA2
               32           20            MT LDP IPv6 prefix

                   Figure 6: new sub-types New Sub-Types for sub-TLVs Sub-TLVs
   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 = TBA5(MT 31 (MT LDP IPv4 FEC)  |          Length = 8           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          IPv4 prefix                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Prefix Length |      MBZ      |       MT-ID                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 7: MT LDP IPv4 FEC sub-TLV 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 (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.

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 = TBA6(MT 32 (MT LDP IPv6 FEC)  |          Length = 20          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                          IPv6 prefix                          |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Prefix Length |     MBZ       |       MT-ID                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 8: MT LDP IPv6 FEC sub-TLV 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 (Multi-
   Topology ID).  The Length for this sub-TLV is 17.

4.3.4.  Operation Considerations

   To detect data plane data-plane failures using LSP Ping ping for a specific topology,
   the router will initiate an LSP Ping 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 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 [RFC4379] the processing rules. 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 module modules for an MPLS LSR
   [RFC3813] and MPLS LDP managed objects[RFC3815] 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.

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 which that is not locally known or not
   supported.  The LSR MUST also discard the entire message before
   sending the Notification. 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 which that does not support MT should not receive any MT
   related
   MT-related LDP messages.  In case the 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 draft, document, we include
   some forwarding consideration for informational purpose purposes here.

   The specified signaling mechanisms allow all the topologies to share
   the platform-specific label space, space.  This feature allows the existing
   data plane
   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 Consideration Considerations

   The use of MT over existing MPLS solutions does not offer any
   specific security benefit.

   General LDP Communication communication security threats and how these may be
   mitigated are described in [RFC5036], [RFC5036]; these threats include:

   o  Spoofing  spoofing

   o  Privacy  privacy
   o  Denial  denial of Service service

   For further discussion regarding possible LDP communication threats
   and mitigation techniques techniques, see [RFC5920].

9.  IANA Considerations

   The

   This document introduces the following new protocol elements that require
   IANA consideration and assignments: elements, which
   have been assigned by IANA:

   o  New LDP Capability TLV: "Multi-Topology Capability" TLV (requested
      code point: TBA1 (0x050C)
      from the LDP Parameters registry "TLV Type Name Space".  We
      suggest to have a value in the range 0x050C-0x05FF).

   o  New Status Code: "Invalid Topology ID" (requested code point: TBA2 (0x00000031) from the LDP
      Parameters registry "Status Code Name Space").

        Registry:
        Range/Value          Description
        --------------       ------------------------------
            TBA2
        0x00000031           Invalid Topology ID
            This new Status Code should be added to
            the range 0x00000000-0x1FFFFFFF (IETF Consensus).

      Figure 9: New Code Points Point for LDP Multi Topology Multi-Topology Extensions

   o  New address families under the IANA registry "Address Family
      Numbers":

      -

         Number       Description
         --------     ------------------------------------
         29           MT IP: Multi-Topology IP version 4 (requested codepoint: 26)
      -
         30           MT IPv6: Multi-Topology IP version 6 (requested codepoint: 27)

                Figure 10: Address Family Numbers
   o  New registry "MPLS Multi-Topology Identifiers".

      This registry should be is a sub-registry 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              [This.I-D]               RFC 7307
      1            IPv4 in-band management                [This.I-D]                 RFC 7307
      2            IPv6 routing topology                  [This.I-D]                   RFC 7307
      3            IPv4 multicast topology                [This.I-D]                 RFC 7307
      4            IPv6 multicast topology                [This.I-D]                 RFC 7307
      5            IPv6 in-band management                [This.I-D]                 RFC 7307
      6-3995       Unassigned for future IGP topologies   [This.I-D]    RFC 7307
                   Assigned by Standards Action           [This.I-D]            RFC 7307
      3996-4095    Experimental                           [This.I-D]                            RFC 7307
      4096-65534   Unassigned for MPLS topologies         [This.I-D]          RFC 7307
                   Assigned by Standards Action
      65535        Wildcard Topology                      [This.I-D]                       RFC 7307

          Figure 11: MPLS Multi-Topology Identifier registry Registry

   o  New Sub-TLV Types for LSP ping: Following 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, and "TLVs and sub-TLVs" sub-registry. registry.

               Sub-Type      Value Field
               --------      -----------
             TBA3      ------------------
               31            MT LDP IPv4 prefix
             TBA4
               32            MT LDP IPv6 prefix

            Figure 12: New Sub-TLV Types for LSP ping

   IANA should allocate the next available numbers for these TBAs. Ping

   As highlighted at the end of Section 3.4 (IGP ("IGP MT-ID Mapping and
   Translation),
   Translation"), a new Internet-Draft document will be created to document detail the policy
   and process for allocating new MT-ID values.

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 enable or disable that the LDP
   Multi-Topology capability. Multi-
   Topology capability be enabled or disabled.  It is assumed that the
   mapping of the LDP
   MT ID MT-ID and IGP MT ID MT-ID is manually configured on
   every router by default.  If an automatic mapping between IGP MT IDs MT-IDs
   and LDP MT IDs 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 LDP-MT-enabled network, it may be necessary to
   associate between the LDP label advertisement and the IGP routing
   advertisement, in
   advertisement.  In this case case, the user MUST understand the mapping
   mechanism to convert the IGP MT ID MT-ID to the LDP MT ID. MT-ID.  The method and
   type of mapping mechanism is out of the scope of this document.

10.5.  Requirements On on Other Protocols

   If the LDP MT ID MT-ID has an implicit dependency on IGP MT ID, MT-ID, then the
   corresponding IGP MT features will need to be supported.

10.6.  Impact On on Network Operations

   Mechanisms defined in this document do not have any impact on network
   operations.

11.  Contributors

   Ning So
   Tata Communications
   2613 Fairbourne Cir.
   Plano, TX  75082
   USA

   Email:

   EMail: ning.so@tatacommunications.com

   Raveendra Torvi
   Juniper Networks
   10, Technoogy
   10 Technology Park Drive
   Westford, MA  01886-3140
   US

   Email:

   EMail: rtorvi@juniper.net

   Huaimo Chen
   Huawei Technology
   125 Nagog Technology Park
   Acton, MA  01719
   US

   Emily Chen
   2717 Seville Blvd, Apt 1205, Apt. 1205
   Clearwater, FL 33764
   US

   Email:

   EMail: emily.chen220@gmail.com

   Chen Li
   China Mobile
   53A, Xibianmennei Ave.
   Xunwu District, Beijing  01719
   China

   Email:

   EMail: lichenyj@chinamobile.com

   Lu Huang
   China Mobile
   53A, Xibianmennei Ave.
   Xunwu District, Beijing  01719
   China

12.  Acknowledgement  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
   Atlas, and Loa Anderson for their valuable comments on this draft. 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.

Authors' Addresses

   Quintin Zhao
   Huawei Technology
   125 Nagog Technology Park
   Acton, MA  01719
   US

   Email:
   EMail: quintin.zhao@huawei.com

   Kamran Raza
   Cisco Systems
   2000 Innovation Drive
   Kanata, ON K2K-3E8, MA K2K-3E8
   Canada

   Email: E-mail:
   EMail: skraza@cisco.com

   Chao Zhou
   Cisco Systems
   300 Beaver Brook Road
   Boxborough, MA  01719
   US

   Email:
   EMail: czhou@cisco.com

   Luyuan Fang
   Microsoft

   Email:
   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:
   EMail: lilianyuan@chinamobile.com

   Daniel King
   Old Dog Consulting

   Email:
   EMail: daniel@olddog.co.uk