[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-zhao-mpls-ldp-multi-topology) 00 01 02 03 04 05 06 07 08 09 10 11 12 RFC 7307

Internet Engineering Task Force                                  Q. Zhao
Internet-Draft                                         Huawei Technology
Intended status: Standards Track                                 L. Fang
Expires: April 9, 2012                                           C. Zhou
                                                           Cisco Systems
                                                                   L. Li
                                                             ChinaMobile
                                                                   N. So
                                                        Verison Business
                                                                R. Torvi
                                                        Juniper Networks
                                                         October 7, 2011






                LDP Extension for Multi Topology Support
               draft-ietf-mpls-ldp-multi-topology-00.txt

Abstract

   Multi-Topology (MT) routing is supported in IP through extension of
   IGP protocols, such as OSPF and IS-IS.  Each route computed by OSPF
   or IS-IS is associated with a specific topology.  Label Distribution
   Protocol (LDP) is used to distribute labels for FECs advertised by
   routing protocols.  It is a natural requirement to extend LDP in
   order to make LDP be aware of MT and thus take advantage of MT based
   routing.

   This document describes options to extend the existing MPLS
   signalling protocol (LDP) for creating and maintaining Label
   Switching Paths (LSPs) in a Multi-Topology enviroment.

Status of this Memo

   This Internet-Draft is submitted to IETF 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



Zhao, et al.              Expires April 9, 2012                 [Page 1]

Internet-Draft        LDP Multi Topology Extension          October 2011


   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 9, 2012.

Copyright Notice

   Copyright (c) 2011 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.              Expires April 9, 2012                 [Page 2]

Internet-Draft        LDP Multi Topology Extension          October 2011


Table of Contents

   1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Application Scenarios  . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Simplified Data-plane  . . . . . . . . . . . . . . . . . .  5
     3.2.  Using MT for p2p Protection  . . . . . . . . . . . . . . .  6
     3.3.  Using MT for mLDP Protection . . . . . . . . . . . . . . .  6
     3.4.  Service Separation . . . . . . . . . . . . . . . . . . . .  6
     3.5.  Simplified inter-AS VPN Solution . . . . . . . . . . . . .  6
   4.  Associating a FEC or group of FECs with MT-ID  . . . . . . . .  7
     4.1.  MT-ID TLV  . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.2.  FEC TLV with MT-ID Extenstion  . . . . . . . . . . . . . .  8
   5.  LDP MT Capability Advertisement  . . . . . . . . . . . . . . .  9
     5.1.  Session Initialization . . . . . . . . . . . . . . . . . . 10
     5.2.  After Session Setup  . . . . . . . . . . . . . . . . . . . 11
   6.  LDP Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 12
   7.  Reserved MT ID Values  . . . . . . . . . . . . . . . . . . . . 12
   8.  LDP Messages with FEC TLV and MT-ID TLV  . . . . . . . . . . . 12
     8.1.  Label Mapping Message  . . . . . . . . . . . . . . . . . . 13
     8.2.  Label Request Message  . . . . . . . . . . . . . . . . . . 14
     8.3.  Label Abort Request Message  . . . . . . . . . . . . . . . 14
     8.4.  Label Withdraw Message . . . . . . . . . . . . . . . . . . 15
     8.5.  Label Release Message  . . . . . . . . . . . . . . . . . . 16
   9.  Session Initialization Message with MT Capability  . . . . . . 16
   10. MPLS Forwarding in MT  . . . . . . . . . . . . . . . . . . . . 17
     10.1. Use Label for (FEC, MT-ID) Tuple . . . . . . . . . . . . . 17
   11. Security Consideration . . . . . . . . . . . . . . . . . . . . 18
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
   13. Acknowledgement  . . . . . . . . . . . . . . . . . . . . . . . 18
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 19
     14.2. Informative References . . . . . . . . . . . . . . . . . . 19
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19

















Zhao, et al.              Expires April 9, 2012                 [Page 3]

Internet-Draft        LDP Multi Topology Extension          October 2011


1.  Terminology

   Terminology used in this document

      MT-ID: A 12 bit value to represent Multi-Topology ID.

      Default Topology: A topology that is built using the MT-ID value
      0.

      MT topology: A topology that is built using the corresponding
      MT-ID.


2.  Introduction

   There are increasing requirements to support multi-topology in MPLS
   network.  For example, service providers may want to assign different
   level of service(s) to different topologies so that the service
   separation can be achieved.  It is also possible to have an in-band
   management network on top of the original MPLS topology, or maintain
   separate routing and MPLS domains for isolated multicast or IPv6
   islands within the backbone, or force a subset of an address space to
   follow a different MPLS topology for the purpose of security, QoS or
   simplified management and/or operations.

   OSPF and IS-IS use MT-ID (Multi-Topology Identification) to identify
   different topologies.  For each topology identified by a MT-ID, IGP
   computes a separate SPF tree independently to find the best paths to
   the IP prefixes associated with this topology.

   For FECs that are associated with a specific topology, we propose to
   use the same MT-ID of this topology in LDP.  Thus the Label Switching
   Path (LSP) for a certian FEC may be created and maintained along the
   IGP path in this topology.

   Maintaining multiple MTs for MPLS network in a backwards-compatible
   manner requires several extensions to the label signaling encoding
   and processing procedures.  When label is associated with a FEC, the
   FEC includes both ip address and topology it belongs to.

   There are two possible solutions to support MT awared MPLS network
   from MPLS forwarding point of view.  The first one is to map label to
   both ip address and the corresponding topology.  The alternative one
   is to use label stacks.  The upper label maps to the topology, the
   lower label maps to the ip address.  The first option does not
   require change to data plane, and it could use multiple labels for
   the same address on different topologies.  The second option requires
   two lookups on data forwarding plane, and it can use the same label



Zhao, et al.              Expires April 9, 2012                 [Page 4]

Internet-Draft        LDP Multi Topology Extension          October 2011


   for the same address on different topologies.

   There are a few possible ways to apply the MT-ID of a topology in
   LDP.  One way is to have a new TLV for MT-ID and insert the TLV into
   messages describing a FEC that needs Multi-Topology information.
   Another approach is to expand the FEC TLV to contain MT-ID if the FEC
   needs Multi-Topology information.

   MT based MPLS in general can be used for a variety of purposes such
   as service separation by assigning each service or a group of
   services to a topology, where the managment, QoS and security of the
   service or the group of the services can be simplified and
   guaranteed, in-band management network "on top" of the original MPLS
   topology, maintain separate routing and MPLS forwrding domains for
   isolated multicast or IPv6 islands within the backbone, or force a
   subset of an address space to follow a different MPLS topology for
   the purpose of security, QoS or simplified management and/or
   operations.

   One of the use of the MT based MPLS is where one class of data
   requires low latency links, for example Voice over Internet Protocol
   (VoIP) data.  As a result such data may be sent preferably via
   physical landlines rather than, for example, high latency links such
   as satellite links.  As a result an additional tolology is defined as
   all low latency links on the network and VoIP data packets are
   assinged to the additional topology.  Another example is security-
   critical traffic which may be assigned to an additional topology for
   non-radiative links.  Further possible examples are file transfer
   prtocol (FTP) or SMTP (simple mail transfer protocol) traffic which
   can be assigned to additional topology comprising high latency links,
   Internet Protocol version 4 (IPv4) versus Internet Protocol version 6
   (IPv6) traffic which may be assigned to different topology or data to
   be distingushed by the quality of service (QoS) assinged to it.


3.  Application Scenarios

3.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
   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



Zhao, et al.              Expires April 9, 2012                 [Page 5]

Internet-Draft        LDP Multi Topology Extension          October 2011


   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.

3.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.

3.3.  Using MT for mLDP Protection

   Fro 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
   priamry LSP in the appplicaitons such 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
   guranteed 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 independantly within each topology.  The two LSPs setup by
   this mechanism can protect each other end-to-end.

3.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 CoS 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.

3.5.  Simplified inter-AS VPN Solution

   When the lsp is crossing multiple domains for the inter-as VPN
   scenarios, the LSP setup process can be simplified by configuring a



Zhao, et al.              Expires April 9, 2012                 [Page 6]

Internet-Draft        LDP Multi Topology Extension          October 2011


   set of routers which are in different domains into a new single
   domain with a new toplogy ID using the LDP multiple topology.  All
   the routers belong this new topology will be used to carry the
   traffic acrossing multiple domains and since they are in a sinle
   domain with the new topology ID, so the LDP lsp set up can be done
   easily without the complex inter-as VPN solution's option A, option B
   and option C.


4.  Associating a FEC or group of FECs with MT-ID

   This section describes two approaches to associate a FEC or a group
   of FECs to a MT-ID in LDP.  One way is to have a new TLV for MT-ID
   and insert the MT-ID TLV into messages describing a FEC that needs
   Multi-Topology information.  Another approach is to extend FEC TLV to
   contain the MT-ID if the FEC needs Multi-Topology information.

4.1.  MT-ID TLV

   The new TLV for MT-ID is defined as below:































Zhao, et al.              Expires April 9, 2012                 [Page 7]

Internet-Draft        LDP Multi Topology Extension          October 2011


       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| TLV Code Point(TBD)       |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            reserved                     |  MT-ID              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where:
     U and F bits:
       As specified in [RFC3036].

     TLV Code Point:
       The TLV type which identifies a specific capability.

     MT-ID is a 12-bit field containing the ID of the topology
     corresponding to the MT-ID used in IGP and LDP. Lack of MT-ID TLV
     in messages MUST be interpreted as FECs are used in default
     MT-ID (0) only.

    A MT-ID TLV can be inserted into the following LDP messages as
    an optional parameter.

      Label Mapping           "Label Mapping Message"
      Label Request           "Label Request Message"
      Label Abort Request     "Label Abort Request Message"
      Label Withdraw          "Label Withdraw Message"
      Label Release           "Label Release Message"

    The message with inserted MT-ID TLV associates a FEC in same message
    to the topology identified by MT-ID.


                        Figure 1: MT-ID TLV Format

4.2.  FEC TLV with MT-ID Extenstion

   The new TLV for MT-ID is defined as below:













Zhao, et al.              Expires April 9, 2012                 [Page 8]

Internet-Draft        LDP Multi Topology Extension          October 2011


     The extended FEC TLV has the format 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |U|F| FEC (TBD)                 |      Length                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            reserved                     |  MT-ID              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        FEC Element 1                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     ~                                                               ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        FEC Element n                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      This new FEC TLV may contain a number of FEC elements and a MT-ID.
      It associates these FEC elements with the topology identified by
      the MT-ID. Each FEC TLV can contain only one MT-ID.

                     Figure 2: Extended FEC with MT-ID


5.  LDP MT Capability Advertisement

   The LDP MT capability can be advertised either during the LDP session
   initailizatin or after the LDP session is setup.

   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 LDP session is
   established, the MT capability can also be advertised or changed
   using Capability message.

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

   If an LSR receives a Label Mapping message with 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.

   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).




Zhao, et al.              Expires April 9, 2012                 [Page 9]

Internet-Draft        LDP Multi Topology Extension          October 2011


   If an LSR is changed from MT capable to non-MT capable, it may
   initiate withdraw of all label mapping for existing LSPs of all non-
   default MTs.  Alternatively, it may wait until the routing update to
   withdraw FEC and release the label mapping for existing LSPs of
   specific MT.

   There will be case where IGP is MT capable but MPLS is not and the
   handling procedure for this case is TBD.

5.1.  Session Initialization

   In an LDP session initialization, the MT capability may be advertised
   through an extended session initailization message.  This extended
   message has the same format as the original session initialization
   message but contains the LDP MT capability TLV as an optional
   parameter.

   The format of the TLV for LDP MT is specified in the [LDPCAP] as
   below:
































Zhao, et al.              Expires April 9, 2012                [Page 10]

Internet-Draft        LDP Multi Topology Extension          October 2011


        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| TLV Code Point(TBD)       |            Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |S| Reserved    |                                               |
       +-+-+-+-+-+-+-+-+       Capability Data                         |
       |                                               +-+-+-+-+-+-+-+-+
       |                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


    where:
      U and F bits:
        As specified in [RFC3036].

      TLV Code Point:
        The TLV type which identifies a specific capability.  The "IANA
        Considerations" section of [RFC3036] specifies the assignment of
        code points for LDP TLVs.

      S-bit:
        The State Bit indicates whether the sender is advertising or
        withdrawing the capability corresponding to the TLV Code Point.
        The State bit is used as follows:

            1 - The TLV is advertising the capability specified by the
                TLV Code Point.
            0 - The TLV is withdrawing the capability specified by the
                TLV Code Point.

      Capability Data:

        Information, if any, about the capability in addition to the TLV
        Code Point required to fully specify the capability.

                         Figure 3: LDP MT CAP TLV

5.2.  After Session Setup

   During the normal operating stage of LDP sessions, the capability
   message defined in the [LDPCAP] will be used with an LDP MT
   capability TLV.

   The format of the Capability message is as follows:






Zhao, et al.              Expires April 9, 2012                [Page 11]

Internet-Draft        LDP Multi Topology Extension          October 2011


        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |0|    Capability (IANA)        |            Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Message ID                                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     TLV_1 (LDP-MT Capability TLV)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     . . .                                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     TLV_N                                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                         Figure 4: LDP CAP Format

   where TLV_1 (LDP-MT Capability TLV) specifies that the LDP MT
   capability is enabled or disbabled by setting the S bit of the TLV to
   1 or 0.


6.  LDP Sessions

   Depending on the number of label spaces supported, if a single gloabl
   label space is supported, there will be one session supported for
   each pair of peers, even there are multiple topologoies supported
   between these two 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 suggested to
   establish multiple sessions for multipple topologies between these
   two peers.  In this case, multiple LSR-IDs need to be allocated
   beforehand so that each multiple topology can have its own label
   space ID.

   This section is still TBD.


7.  Reserved MT ID Values

   Certain MT topologies are assigned to serve pre-determined purposes:
   [TBD]


8.  LDP Messages with FEC TLV and MT-ID TLV





Zhao, et al.              Expires April 9, 2012                [Page 12]

Internet-Draft        LDP Multi Topology Extension          October 2011


8.1.  Label Mapping Message

   An LSR sends a Label Mapping message to an LDP peer to advertise FEC-
   label bindings.  In the Optional Parameters' field, the MT-ID TLV
   will be inserted.

   The encoding for the Label Mapping message 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|   Label Mapping (0x0400)    |      Message Length           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Message ID                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     FEC TLV                                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Label TLV                                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     MT-ID TLV                                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Other Optional Parameters                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      Optional Parameters
         This variable length field contains 0 or more parameters, each
         encoded as a TLV.  The optional parameters are:

            Optional Parameter    Length       Value

            Label Request         4            See below
                Message ID TLV
            Hop Count TLV         1            See below
            Path Vector TLV       variable     See below
            MT TLV                variable     See below


         MT TLV
            see the defination section for this new TLV.



                      Figure 5: Label Mapping Message







Zhao, et al.              Expires April 9, 2012                [Page 13]

Internet-Draft        LDP Multi Topology Extension          October 2011


8.2.  Label Request Message

   An LSR sends the Label Request message to an LDP peer to request a
   binding (mapping) for a FEC.  The MT TLV will be inserted into the
   Optional parameters' field.

   The encoding for the Label Request message 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|   Label Request (0x0401)    |      Message Length           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Message ID                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     FEC TLV                                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     MT-ID TLV                                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Optional Parameters                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                      Figure 6: Label Request Message

   In the DU mode, when a label mapping is received by a LSR which has a
   downstream with MT capability advertised and an upstream without the
   MT capability advertised, it will not send label mapping to its
   upstream.

   in the DoD mode, the label request is sent down to the downstream LSR
   until it finds the downstrream LSR which doesn't support the MT, then
   the current LSPR will send a notification to its upstream LSR.  In
   this case, no LSP is setup.

   We propose to add a new notification event to signal the upstream
   that the downstream is not capable.

8.3.  Label Abort Request Message

   The Label Abort Request message may be used to abort an outstanding
   Label Request message.  The MT TLV may be inserted into the optional
   parameters' field.

   The encoding for the Label Abort Request message is:






Zhao, et al.              Expires April 9, 2012                [Page 14]

Internet-Draft        LDP Multi Topology Extension          October 2011


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|   Label Abort Req (0x0404)  |      Message Length           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Message ID                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     FEC TLV                                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Label Request Message ID TLV              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     MT-ID TLV  (optional)                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Optional Parameters                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                   Figure 7: Label Abort Request Message

8.4.  Label Withdraw Message

   An LSR sends a Label Withdraw Message to an LDP peer to signal the
   peer that the peer may not continue to use specific FEC-label
   mappings the LSR had previously advertised.  This breaks the mapping
   between the FECs and the labels.  The MT TLV will be added into the
   optional paramters' field.

   The encoding for the Label Withdraw Message 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|   Label Withdraw (0x0402)   |      Message Length           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Message ID                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     FEC TLV                                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Label TLV (optional)                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     MT-ID TLV                                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Optional Parameters                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                     Figure 8: Label Withdraw Message




Zhao, et al.              Expires April 9, 2012                [Page 15]

Internet-Draft        LDP Multi Topology Extension          October 2011


8.5.  Label Release Message

   An LSR sends a Label Release message to an LDP peer to signal the
   peer that the LSR no longer needs specific FEC-label mappings
   previously requested of and/or advertised by the peer.  The MT TLV
   will be added into the optional paramers' field.

   The encoding for the Label Release Message 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|   Label Release (0x0403)   |      Message Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Message ID                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     FEC TLV                                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Label TLV (optional)                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     MT-ID TLV                                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Optional Parameters                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                      Figure 9: Label Release Message


9.  Session Initialization Message with MT Capability

   The session initializtion message is extended to contain the LDP MT
   capability as an optional parameter.  The extended session
   initialization message has the format below.
















Zhao, et al.              Expires April 9, 2012                [Page 16]

Internet-Draft        LDP Multi Topology Extension          October 2011


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|   Initialization (0x0200)   |      Message Length           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Message ID                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Common Session Parameters TLV             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     LDP MT Capability TLV                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Optional Parameters                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


       Figure 10: Session  Initialization Message with MT Capability


10.  MPLS Forwarding in MT

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

   In MT based MPLS network, forwarding will be based not only on label,
   but also on MT-ID associsted with the label.  There are multiple
   options to do this.  Below, we list the option prefered.

10.1.  Use Label for (FEC, MT-ID) Tuple

   We suggest is that MPLS forwarding for different topologies is
   implied by labels.  This approach does not need any change to the
   exsiting MPLS hardware forwarding mechanism.  It also resolves the
   forwarding issue that exists in IGP multi-topology forwarding when
   multiple topologies share an interface with overlay address space.

   On a MT awared LSR, each label is associated with tuple: (FEC,
   MT-ID).  Therefore, same FEC with different MT-ID would be assigned
   to different labels.

   Using this mechanism, for tuple (FEC-F, MT-ID-N1) and (FEC-F,
   MT-ID-N2), each LSR along the LSP path that is shared by topology MT-
   ID-N1 and MT-ID-N2 will allocate different labels to them.  Thus two
   different Label Switching Paths will be created.  One for (FEC-F, MT-
   ID-N1) and the other for (FEC-F, MT-ID-N1).  The traffic for them
   will follow different Label Switching Paths (LSPs).

   Note, in this mechanism, label space is not allowed to be overlapping



Zhao, et al.              Expires April 9, 2012                [Page 17]

Internet-Draft        LDP Multi Topology Extension          October 2011


   among different MTs.  In the above example, each label belongs to a
   specific topology or the default topology.  MPLS forwarding will be
   performed exactly same as non-MT MPLS forwarding: using label to find
   output information.  This option will not require any change of
   hardware forwarding to commodate MPLS MT.  We will have different
   RIBs coresspoding to different MT IDs.  But we will only need one
   LFIB.




       Below is an example for MPLS forwarding:

           RIB(x) for MT-IDx:
                   FEC                       NEXT HOP
                   FECi(Destination A)       R1

           RIB(y) for MT-IDy:
                   FEC                       NEXT HOP
                   FECi(Destination A)       R2

           LFIB:
                   Ingress Label  Egress Label       NEXT HOP
                   Lm             Lp                 R1
                   Ln             Lq                 R2 (could be same as R1)




                      Figure 11: Forwarding Mechanism


11.  Security Consideration

   MPLS security applies to the work presented.  No specific security
   issues with the proposed solutions are known.  The authentication
   procedure for RSVP signalling is the same regardless of MT
   information inside the RSVP messages.


12.  IANA Considerations

   TBD


13.  Acknowledgement

   The authors would like to thank Dan Tappan, Nabil Bitar, and Huang



Zhao, et al.              Expires April 9, 2012                [Page 18]

Internet-Draft        LDP Multi Topology Extension          October 2011


   Xin for their valuable comments on this draft.


14.  References

14.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.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC4915]  Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
              Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
              RFC 4915, June 2007.

   [RFC5120]  Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
              Topology (MT) Routing in Intermediate System to
              Intermediate Systems (IS-ISs)", RFC 5120, February 2008.

14.2.  Informative References


Authors' Addresses

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

   Email: qzhao@huawei.com


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

   Email: huaimochen@huawei.com





Zhao, et al.              Expires April 9, 2012                [Page 19]

Internet-Draft        LDP Multi Topology Extension          October 2011


   Emily Chen
   Huawei Technology
   No. 5 Street, Shangdi Information, Haidian
   Beijing
   China

   Email: chenying220@huawei.com


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

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


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

   Email: lufang@cisco.com








Zhao, et al.              Expires April 9, 2012                [Page 20]

Internet-Draft        LDP Multi Topology Extension          October 2011


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

   Email: czhou@cisco.com


   Ning So
   Verison Business
   2400 North Glenville Drive
   Richardson, TX  75082
   USA

   Email: Ning.So@verizonbusiness.com


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

   Email: pratiravi@juniper.net


























Zhao, et al.              Expires April 9, 2012                [Page 21]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/