Internet Engineering Task Force                                  Q. Zhao
Internet-Draft                                         Huawei Technology
Intended status: Standards Track                                 L. Fang
Updates: RFC4379                                                 C. Zhou
Expires: April 25, 2013                                    Cisco Systems
                                                                   L. Li
                                                            China Mobile
                                                                   N. So
                                                     Tata Communications
                                                                 K. Raza
                                                           Cisco Systems
                                                        October 22, 2012

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

Abstract

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

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

Status of this Memo

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

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

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 6, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the



Zhao, et al.              Expires April 25, 2013                [Page 1]


Internet-Draft        LDP Multi Topology Extensions         October 2012


   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.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.




























Zhao, et al.              Expires April 25, 2013                [Page 2]


Internet-Draft        LDP Multi Topology Extensions         October 2012


Table of Contents

   1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  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  . . . . . . . . . . . . .  8
     3.6.  Procedures . . . . . . . . . . . . . . . . . . . . . . . .  9
     3.7.  LDP Sessions . . . . . . . . . . . . . . . . . . . . . . . 10
     3.8.  Reserved MT ID Values  . . . . . . . . . . . . . . . . . . 10
   4.  MT Applicability on FEC-based features . . . . . . . . . . . . 10
     4.1.  Typed Wildcard FEC Element . . . . . . . . . . . . . . . . 10
     4.2.  End-of-LIB . . . . . . . . . . . . . . . . . . . . . . . . 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  . . . . . . . . . . . . . . . 12
       4.3.4.  Operation Considerations . . . . . . . . . . . . . . . 13
   5.  Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 13
     5.1.  MT Error Notification for Invalid Topology ID  . . . . . . 13
   6.  Backwards Compatibility  . . . . . . . . . . . . . . . . . . . 14
   7.  MPLS Forwarding in MT  . . . . . . . . . . . . . . . . . . . . 14
   8.  Security Consideration . . . . . . . . . . . . . . . . . . . . 14
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16
   11. Acknowledgement  . . . . . . . . . . . . . . . . . . . . . . . 17
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 17
     12.2. Informative References . . . . . . . . . . . . . . . . . . 18
   Appendix A.  Appendix  . . . . . . . . . . . . . . . . . . . . . . 18
     A.1.  Requirements . . . . . . . . . . . . . . . . . . . . . . . 18
     A.2.  Application Scenarios  . . . . . . . . . . . . . . . . . . 18
       A.2.1.  Simplified Data-plane  . . . . . . . . . . . . . . . . 18
       A.2.2.  Using MT for P2P Protection  . . . . . . . . . . . . . 19
       A.2.3.  Using MT for mLDP Protection . . . . . . . . . . . . . 19
       A.2.4.  Service Separation . . . . . . . . . . . . . . . . . . 19
       A.2.5.  An Alternative inter-AS VPN Solution . . . . . . . . . 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20










Zhao, et al.              Expires April 25, 2013                [Page 3]


Internet-Draft        LDP Multi Topology Extensions         October 2012


1.  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].


2.  Introduction

   Multi-Topology (MT) routing is supported in IP networks with the use
   of MT aware IGP protocols.  It would be advantageous for
   communications Service Providers (CSP) to support Multiple Topologies
   (MT) within MPLS environments (MPLS-MT).  Beneficial MPLS-MT
   deployment applications include:

   o  A CSP may want to assign varying QoS profiles to traffic, based on
      a specific MT.

   o  Separate routing and MPLS domains may be used to isolated
      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 could be separated from customer traffic using
      multiple MTs, where the management traffic MT does not use links
      that carries customer traffic.

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

   This document also updates RFC4379 by defining two new FEC types for
   LSP ping.




Zhao, et al.              Expires April 25, 2013                [Page 4]


Internet-Draft        LDP Multi Topology Extensions         October 2012


3.  Signaling Extensions

3.1.  Topology-Scoped Forwarding Equivalence Class (FEC)

   LDP assigns and binds a label to a Forwarding Equivalence Class
   (FEC), where a FEC is a list of one of more FEC elements.  To setup
   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
   setup along the routing path.  To setup MT LSPs for IP prefixes under
   a given topology scope, the LDP "prefix-related" FEC element must be
   extended to include topology information.  This infers that MT-ID
   becomes an attribute of Prefix-related FEC element, and all FEC-Label
   binding operations are performed under the context of given topology
   (MT-ID).

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

3.2.  New Address Families: MT IP

   The LDP base specification [RFC5036] (Section 4.1) defines the
   "Prefix" FEC Element 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            |     PreLen    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Prefix                                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


              Figure 1: Prefix FEC  Element Format [RFC5036]

   Where "Prefix" encoding is as defined for given "Address Family", and
   whose length (in bits) is 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 Family is:







Zhao, et al.              Expires April 25, 2013                [Page 5]


Internet-Draft        LDP Multi Topology Extensions         October 2012


        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
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                     IP Address                                |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |          Reserved             |        MT-ID                  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 2: MT IP 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 Topology ID for given address.

   Where 16-bit "MT-ID" field defines the Topology ID, and the
   definition and usage of the rest fields in the FEC Elements are same
   as defined for IP/IPv6 AF.  The value of MT-ID 0 corresponds to
   default topology and MUST be ignored on receipt so as to not cause
   any conflict/confusion with existing non-MT procedures.

   The proposed 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.

   [Editors Note - RFC[5036] doesn't specify the handling of unknown
   Address Family.  After we have introduced the two new address family
   here, RFC[5036] need to be updated to add the handling procedure for
   the unknown address families.

3.3.  LDP FEC Elements with MT IP AF

   The following section specifies the format extensions of the existing
   LDP FEC Elements.  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                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Zhao, et al.              Expires April 25, 2013                [Page 6]


Internet-Draft        LDP Multi Topology Extensions         October 2012


                  Figure 3: MT Prefix FEC Element Format

   Similarly, the MT mLDP FEC elements encoding is as follows, where the
   mLDP FEC Type can be P2MP(6), MP2MP-up(7), and MP2MP-down(8):


        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | mLDP FEC Type | Address Family (MT IP/MT IPv6)| Address Length|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                       Root Node Address                       ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          Reserved             |        MT-ID                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Opaque Length              |    Opaque Value ...           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
       ~                                                               ~
       |                                                               |
       |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 4: MT mLDP 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                 |
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 5: MT Typed Wildcard FEC Element

3.4.  IGP MT-ID Mapping and Translation

   The non-reserved non-special IGP MT-ID values can be used/carried in
   LDP as-is and need no translation.  However, there is a need for
   translating reserved/special IGP MT-ID values to corresponding LDP
   MT-IDs.  The corresponding special/reserved LDP MT-ID values are
   defined in later section 10.






Zhao, et al.              Expires April 25, 2013                [Page 7]


Internet-Draft        LDP Multi Topology Extensions         October 2012


3.5.  LDP MT Capability Advertisement

   We specify a new LDP capability, named "Multi-Topology (MT)", which
   is defined in accordance with LDP Capability definition 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 to announce LSR capability to support
   MTR for the given IP address family.

   The "MT" capability is specified using "Multi-Topology Capability"
   TLV.  The "Multi-Topology Capability" TLV format is in accordance
   with LDP capability guidelines as defined in [RFC5561].  To be able
   to specify IP address family, the capability specific data (i.e.
   "Capability Data" field of Capability TLV) is populated using "Typed
   Wildcard FEC Element" as defined in [RFC5918].

   The format of "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 6: Multi-Topology Capability TLV Format

   o  Where:

   o  U- and F-bits: MUST be 1 and 0, respectively, as per Section 3.
      (Signaling Extensions) 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: The length (in octets) of TLV.





Zhao, et al.              Expires April 25, 2013                [Page 8]


Internet-Draft        LDP Multi Topology Extensions         October 2012


   o  The encoding of Typed Wildcard FEC element, as defined in
      [RFC5561], is defined in the section 4.1 (Typed Wildcard FEC
      Element) of this document.

3.6.  Procedures

   To announce its MT capability for an IP address family, LDP FEC type,
   and Multi Topology, an LDP speaker MAY send an "MT Capability"
   including the exact Typed Wildcard FEC element with 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 "P2P", "P2MP", "MP2MP"), and corresponding "MT-ID".  To
   announce its MT capability for both IPv4 and IPv6 address family, or
   for multiple FEC types, or for multiple Multi Topologies, an LDP
   speaker MAY send "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 Capability message (only if "Dynamic
      Announcement" capability [RFC5561] has already been successfully
      negotiated).

   o  If an LSR has not advertised MT capability, its peer must not send
      messages that include MT identifier to this LSR.

   o  If an LSR receives a Label Mapping message with an MT parameter
      from downstream LSR-D and its upstream LSR-U has not advertised MT
      capability, an LSP for the MT will not be established.

   o  This document proposes to add a new notification event to signal
      the upstream that the downstream is not capable.

   o  If an LSR is changed from non-MT capable to MT capable, it sets
      the S bit in MT capability TLV and advertises via the Capability
      message.  The existing LSP is treated as LSP for default MT (ID
      0).

   o  If an LSR is changed from LDP-MT capable to non-MT capable, it may
      initiate withdraw of all label mapping for existing LSPs of all
      non-default MTs.  Then it clears the S bit in MT capability TLV
      and advertises via the Capability message.

   o  If an LSR is changed from IGP-MT capable to non-MT capable, it may
      wait until the routes update to withdraw FEC and release the label
      mapping for existing LSPs of specific MT.



Zhao, et al.              Expires April 25, 2013                [Page 9]


Internet-Draft        LDP Multi Topology Extensions         October 2012


3.7.  LDP Sessions

   If a single global label space is supported, there will be an LDP
   session supported for each pair of peers, regardless of the number of
   MTs supported between peers.  If there are different label spaces
   supported for different topologies, which means that label spaces
   overlap with each other for different MTs, then it is recommended to
   establish multiple sessions for multiple topologies between these two
   peers.  In this case, multiple LSR-IDs will need to be allocated so
   that each multiple topology can have its own label space ID.

3.8.  Reserved MT ID Values

   Certain MT topologies are assigned to serve predetermined purposes:

   Default-MT: Default topology.  This corresponds to OSPF default IPv4
   and IPv6, as well as ISIS default IPv4.  A value of 0 is proposed.

   ISIS IPv6 MT: ISIS default MT-ID for IPv6.

   Wildcard-MT: This corresponds to All-Topologies.  A value of 65535
   (0xffff) is proposed.

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

   If an LSR receives a FEC element with an "MT-ID" value that is
   "Reserved" 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 MT-ID" to the sender.


4.  MT Applicability on FEC-based features

4.1.  Typed Wildcard FEC Element

   [RFC5918] extends base LDP and defines Typed Wildcard FEC Element
   framework.  Typed Wildcard FEC element can be used in any LDP message
   to specify a wildcard operation/action for given type of FEC.

   The MT extensions proposed in document do not require any extension
   in procedures for 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.



Zhao, et al.              Expires April 25, 2013               [Page 10]


Internet-Draft        LDP Multi Topology Extensions         October 2012


   The proposed 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 wildcard operation that
   applies to all topologies, it can use a "Wildcard Topology" MT-ID.
   For example, upon local configuration of topology "x", an LSR may
   send a wildcard label withdraw request with MT-ID "x" to withdraw all
   its labels from the peer that advertized under the scope of topology
   "x".  Additionally, upon a global configuration change, an LSR may
   send a wildcard label withdraw with the MT-ID set to "Wildcard
   Topology" to withdraw all its labels under all topologies from the
   peer.

4.2.  End-of-LIB

   [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 to an MT FEC element.
   This MAY allow 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.  The 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 LSPs 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 [RFC-4379] defines Sub-Types and
   format for the FEC.  To support LSP ping for MT LDP LSPs, this
   document proposes following extensions to [RFC-4379].

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 following new sub-types for sub-TLVs to specify these
   FECs in the "Target FEC Stack" TLV of [RFC-4379]:






Zhao, et al.              Expires April 25, 2013               [Page 11]


Internet-Draft        LDP Multi Topology Extensions         October 2012


         Sub-Type       Length            Value Field
         --------       ------            -----------------
               24            5            MT LDP IPv4 prefix
               25           17            MT LDP IPv6 prefix

                   Figure 7: new sub-types for sub-TLVs

   The rules and procedures of using these sub-TLVs in an MPLS echo
   request message are same as defined for LDP IPv4/IPv6 FEC sub-TLV
   types in [RFC-4379].

4.3.2.  MT LDP IPv4 FEC Sub-TLV

   The format of "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 = 24 (MT LDP IPv4 FEC)  |          Length = 8           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          IPv4 prefix                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Prefix Length |      MBZ      |       MT-ID                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 8: MT LDP IPv4 FEC sub-TLV

   The format of this sub-TLV is similar to LDP IPv4 FEC sub-TLV as
   defined in [RFC-4379].  In addition to "IPv4 prefix" and "Prefix
   Length" fields, this new sub-TLV also specifies MT-ID (Multi-Topology
   ID).  The Length for this sub-TLV is 5.

4.3.3.  MT LDP IPv6 FEC Sub-TLV

   The format of "MT LDP IPv6 FEC" sub-TLV to be used in a "Target FEC
   Stack" [RFC4379] is:














Zhao, et al.              Expires April 25, 2013               [Page 12]


Internet-Draft        LDP Multi Topology Extensions         October 2012


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

                     Figure 9: MT LDP IPv6 FEC sub-TLV

   The format of this sub-TLV is similar to LDP IPv6 FEC sub-TLV as
   defined in [RFC-4379].  In addition to "IPv6 prefix" and "Prefix
   Length" fields, this new sub-TLV also specifies MT-ID (Multi-Topology
   ID).  The Length for this sub-TLV is 17.

4.3.4.  Operation Considerations

   When detect data-plane failures using LSP Ping for a specific topoly,
   the router will intiate an LSP Ping request with the targer FEC stack
   TLV containing LDP MT IP Prefix Sub-TLV in the Echo Request packet.
   The Echo Request packet is sent with the label binded to the IP
   Prefix in the topolgy.  Once the echo request packet reaches the
   target router, it will process the packet and perform checs for the
   LDP MT IP Prefix sub-TLV present in the Target FEC Stack as described
   in [RFC4379] and respond according to [RFC4379] processing rules.
   For the case that the LSP ping with return path not specified , the
   reply packet may go through the default topology instead of the
   topology where the Echol Request goes through.


5.  Error Handling

   The extensions defined in this document utilise the existing LDP
   error handling defined in [RFC5036].  If an LSR receives an error
   notification from a peer for an MPLS-MT session, it terminates the
   LDP session by closing the TCP transport connection for the session
   and discarding all MT-ID label mappings learned via the session.

5.1.  MT Error Notification for Invalid Topology ID

   If an LSR has advertized an MT Capability TLV using the
   Initialization message or Capability message, which includes Typed
   Wildcard FEC elements with specific MT-IDs, and it receives an MT



Zhao, et al.              Expires April 25, 2013               [Page 13]


Internet-Draft        LDP Multi Topology Extensions         October 2012


   message with a MT-ID which is not included in the supported list, it
   should response this "Invalid Topology ID" status code.


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.


7.  MPLS Forwarding in MT

   Although forwarding is out of the scope of this draft, we include
   some forwarding consideration for informational purpose here.

   The specified signaling mechanisms allow all the topologies to share
   the platform-specific label space; this is the feature that allows
   the existing data plane techniques to be used; and the specified
   signaling mechanisms do not provide any way for the data plane to
   associate a given packet with a context-specific label space.


8.  Security Consideration

   No specific security issues with the proposed solutions are known.
   The proposed extensions in this document do not introduce any new
   security considerations beyond that already apply to the base LDP
   specification [RFC5036] and [RFC5920].


9.  IANA Considerations

   The document introduces following new protocol elements that require
   IANA consideration and assignments:

   o  New LDP Capability TLV: "Multi-Topology Capability" TLV (requested
      code point: 0x510 from LDP registry "TLV Type Name Space").

   o  New Status Code: "Multi-Topology Capability not supported"
      (requested code point: 0x50 from LDP registry "Status Code Name
      Space").

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

   o  New Status Code: "Unknown Address Family" (requested code point:
      0x52 from LDP registry "Status Code Name Space").



Zhao, et al.              Expires April 25, 2013               [Page 14]


Internet-Draft        LDP Multi Topology Extensions         October 2012


            Registry:
            Range/Value     E     Description
            --------------  ---   ------------------------------
            0x00000051      1     Invalid Topology ID


       Figure 10: New Status Codes for LDP Multi Topology Extensions

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

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

                      Figure 11: Address Family Numbers

   o  New registry "LDP Multi-Topology (MT) ID Name Space" under "LDP
      Parameter" namespace.  The registry is defined as:


           Range/Value             Name
           -----------             ------------------------
           0                       Default Topology (ISIS and OSPF)
           1-4095                  Unassigned
           4096                    ISIS IPv6 routing topology (i.e. ISIS MT ID #2)
           4097-65534              Reserved (for future allocation)
           65535                   Wildcard Topology (ISIS or OSPF)

             Figure 12: LDP Multi-Topology (MT) ID Name Space

   o  New Sub-TLV Types for LSP ping: Following new sub-type values
      under TLV type 1 (Target FEC Stack) from "Multi-Protocol Label
      Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters"
      registry, and "TLVs and sub-TLVs" sub-registry.



         Sub-Type      Value Field
         --------      -----------
               24      MT LDP IPv4 prefix
               25      MT LDP IPv6 prefix


                 Figure 13: New Sub-TLV Types for LSP ping








Zhao, et al.              Expires April 25, 2013               [Page 15]


Internet-Draft        LDP Multi Topology Extensions         October 2012


10.  Contributors

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

      Email: rtorvi@juniper.net

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

      Email: huaimochen@huawei.com

      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

      Email: huanglu@chinamobile.com

      Daniel King
      Old Dog Consulting

      Email: E-mail: daniel@olddog.co.uk






Zhao, et al.              Expires April 25, 2013               [Page 16]


Internet-Draft        LDP Multi Topology Extensions         October 2012


      Zhenbin Li
      Huawei Technology
      2330 Central Expressway
      Santa Clara, CA  95050
      US

      Email: zhenbin.li@huawei.com




11.  Acknowledgement

   The authors would like to thank Dan Tappan, Nabil Bitar, Huang Xin,
   Eric Rosen, IJsbrand Wijnands, Dimitri Papadimitriou, Yiqun Chai and
   pranjal Dutta for their valuable comments on this draft.


12.  References

12.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3692]  Narten, T., "Assigning Experimental and Testing Numbers
              Considered Useful", BCP 82, RFC 3692, January 2004.

   [RFC5036]  Andersson, L., Minei, I., and B. Thomas, "LDP
              Specification", RFC 5036, October 2007.

   [RFC5919]  Asati, R., Mohapatra, P., Chen, E., and B. Thomas,
              "Signaling LDP Label Advertisement Completion", RFC 5919,
              August 2010.

   [RFC5918]  Asati, R., Minei, I., and B. Thomas, "Label Distribution
              Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class
              (FEC)", RFC 5918, August 2010.

   [RFC6388]  Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas,
              "Label Distribution Protocol Extensions for Point-to-
              Multipoint and Multipoint-to-Multipoint Label Switched
              Paths", RFC 6388, November 2011.

   [RFC4379]  Kompella, K. and G. Swallow, "Detecting Multi-Protocol
              Label Switched (MPLS) Data Plane Failures", RFC 4379,
              February 2006.




Zhao, et al.              Expires April 25, 2013               [Page 17]


Internet-Draft        LDP Multi Topology Extensions         October 2012


12.2.  Informative References

   [RFC5920]  Fang, L., "Security Framework for MPLS and GMPLS
              Networks", RFC 5920, July 2010.

   [IANA-LSPV]
              Multi-Protocol Label Switching (MPLS) Label Switched Paths
              (LSPs) Ping Parameters, "http://www.iana.org/assignments/
              mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xml".


Appendix A.  Appendix

A.1.  Requirements

   The following specific requirements and objectives have been defined
   in order to provide the functionality described in Section 2
   (Introduction), and facilitate CSP configuration and operation:

   o  Minimise configuration and operation complexity of MPLS-MT across
      the network.

   o  The MPLS-MT solution SHOULD NOT require data-plane modification.

   o  The MPLS-MT solution MUST support multiple topologies.  Allowing a
      an MPLS LSP to be established across a specific, or set of,
      multiple topologies.

   o  Control and filtering of LSPs using explicitly including or
      excluding multiple topologies MUST be supported.

   o  The MPLS-MT solution MUST be capable of supporting QoS mechanisms.

   o  The MPLS-MT solution MUST be backwards compatibility with existing
      LDP message authenticity and integrity techniques, and loop
      detection.

   o  Deployment of MPLS-MT within existing MPLS networks should be
      possible, with nodes not capable of MPLS-MT being unaffected.

A.2.  Application Scenarios

A.2.1.  Simplified Data-plane

   IGP-MT requires additional data-plane resources maintain multiple
   forwarding for each configured MT.  On the other hand, MPLS-MT does
   not change the data-plane system architecture, if an IGP-MT is mapped
   to an MPLS-MT.  In case MPLS-MT, incoming label value itself can



Zhao, et al.              Expires April 25, 2013               [Page 18]


Internet-Draft        LDP Multi Topology Extensions         October 2012


   determine an MT, and hence it requires a single NHLFE space.  MPLS-MT
   requires only MT-RIBs in the control-plane, no need to have MT-FIBs.
   Forwarding IP packets over a particular MT requires either
   configuration or some external means at every node, to maps an
   attribute of incoming IP packet header to IGP-MT, which is additional
   overhead for network management.  Whereas, MPLS-MT mapping is
   required only at the ingress-PE of an MPLS-MT LSP, because of each
   node identifies MPLS-MT LSP switching based on incoming label, hence
   no additional configuration is required at every node.

A.2.2.  Using MT for P2P Protection

   We know that [IP-FRR-MT] can be used for configuring alternate path
   via backup-mt, such that if primary link fails, then backup-MT can be
   used for forwarding.  However, such techniques require special
   marking of IP packets that needs to be forwarded using backup-MT.
   MPLS-LDP-MT procedures simplify the forwarding of the MPLS packets
   over backup-MT, as MPLS-LDP-MT procedure distribute separate labels
   for each MT.  How backup paths are computed depends on the
   implementation, and the algorithm.  The MPLS-LDP-MT in conjunction
   with IGP-MT could be used to separate the primary traffic and backup
   traffic.  For example, service providers can create a backup MT that
   consists of links that are meant only for backup traffic.  Service
   providers can then establish bypass LSPs, standby LSPs, using backup
   MT, thus keeping undeterministic backup traffic away from the primary
   traffic.

A.2.3.  Using MT for mLDP Protection

   For the P2MP or MP2MP LSPs setup by using mLDP protocol, there is a
   need to setup a backup LSP to have an end to end protection for the
   primary LSP in the applications such as IPTV, where the end to end
   protection is a must.  Since the mLDP LSP is setup following the IGP
   routes, the second LSP setup by following the IGP routes can not be
   guaranteed to have the link and node diversity from the primary LSP.
   By using MPLS-LDP-MT, two topology can be configured with complete
   link and node diversity, where the primary and secondary LSP can be
   set up independently within each topology.  The two LSPs setup by
   this mechanism can protect each other end-to-end.

A.2.4.  Service Separation

   MPLS-MT procedures allow establishing two distinct LSPs for the same
   FEC, by advertising separate label mapping for each configured
   topology.  Service providers can implement QoS using MPLS-MT
   procedures without requiring to create separate FEC address for each
   class.  MPLS-MT can also be used separate multicast and unicast
   traffic.



Zhao, et al.              Expires April 25, 2013               [Page 19]


Internet-Draft        LDP Multi Topology Extensions         October 2012


A.2.5.  An Alternative inter-AS VPN Solution

   When the LSP is crossing multiple domains for the inter-as VPN
   scenarios, the LSP setup process can be done by configuring a set of
   routers which are in different domains into a new single domain with
   a new topology ID using the LDP multiple topology.  All the routers
   belong this new topology will be used to carry the traffic across
   multiple domains and since they are in a single domain with the new
   topology ID, so the LDP LSP set up can be done without propagating
   VPN routes across AS boundaries.


Authors' Addresses

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

   Email: quintin.zhao@huawei.com


   Luyuan Fang
   Cisco Systems
   300 Beaver Brook Road
   Boxborough, MA  01719
   US

   Email: lufang@cisco.com


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

   Email: czhou@cisco.com












Zhao, et al.              Expires April 25, 2013               [Page 20]


Internet-Draft        LDP Multi Topology Extensions         October 2012


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

   Email: lilianyuan@chinamobile.com


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

   Email: ning.so@tatacommunications.com


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

   Email: E-mail: skraza@cisco.com


























Zhao, et al.              Expires April 25, 2013               [Page 21]