MPLS Working Group                                     IJsbrand Wijnand
Internet Draft                                      Cisco Systems, Inc.
Intended status: Standards Track
Expires: June July 8, 2012                                  Kamran Raza
                                                    Cisco Systems, Inc.


                                                        January 9, 2012


                mLDP Extensions for Multi Topology Routing

              draft-iwijnand-mpls-mldp-multi-topology-01.txt


Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79. This document may not be modified,
   and derivative works of it may not be created, except to publish it
   as an RFC and to translate it into languages other than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on July 8, 2012.

Copyright Notice

   Copyright (c) 2012 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



Wijnands, et. al             Expires July 2012                 [Page 1]


Internet-Draft mLDP Extensions for Multi-Topology Routing  January 2012


   carefully, as they describe your rights and restrictions with
   respect to this document.

Abstract

   The Multi-Topology Routing (MTR) enables service differentiation
   through class-based forwarding. IGP protocols (OSPF and IS-IS) have
   already been extended to setup MTR. In order to deploy mLDP in an
   MTR setup, mLDP is also required to become topology-aware. This
   document specifies extensions to mLDP to support Multi-Topology
   Routing.

Table of Contents

1. Glossary .......................................................... 3
2. Introduction ...................................................... 3
3. Conventions used in this document ................................. 3
4. MT-Scoped mLDP FECs ............................................... 4
 4.1. MP FEC Extensions for MT ....................................... 4
   4.1.1. MP FEC Element ............................................. 4
   4.1.2. MT IP Address Families ..................................... 5
   4.1.3. MT MP FEC Element .......................................... 5
 4.2. Topology IDs ................................................... 6
5. Multipoint MT Capability .......................................... 6
6. MT Applicability on FEC-based features ............................ 7
 6.1. MT Typed Wildcard MP FEC Elements .............................. 7
 6.2. MT End-of-LIB .................................................. 8
7. Topology-Scoped Forwarding ........................................ 9
 7.1. Upstream LSR selection ......................................... 9
 7.2. Downstream forwarding interface ................................ 9
8. Security Considerations ........................................... 9
9. IANA Considerations ............................................... 9
10. References ...................................................... 10
 10.1. Normative References ......................................... 10
 10.2. Informative References ....................................... 10
11. Acknowledgments ................................................. 10








Wijnands, et. al            Expires July 2012                  [Page 2]


Internet-Draft mLDP Extensions for Multi-Topology Routing  January 2012


 Glossary

 MT    - Multi-Topology

 MT-ID - Multi-Topology Identifier

 MTR   - Multi-Topology Routing

 IGP   - Interior Gateway Protocol

 mLDP  - Multi-point LDP

 P2MP  - Point-to-Multipoint

 MP2MP - Multipoint-to-Multipoint

 MP    - Multi-point (P2MP or MP2MP)

 LSP   - Label Switched Path

 Introduction

 The Multi-Topology Routing (MTR) enables service differentiation
 through class-based forwarding. For example, MTR can be used to
 define separate IP topologies for voice, video, and data traffic
 classes. To support MTR, an IGP maintains independent IP topologies,
 termed as "Multi-Topologies" (MT), and computes/installs routes per
 topology. OSPF extensions [RFC4915] and ISIS extensions [RFC5120]
 specify the MT extensions under respective IGP. To support IGP MT,
 similar extensions [MT-LDP] have been proposed in LDP to make LDP
 MT-aware, and be able to setup unicast Label Switched Paths (LSPs)
 along IGP MT routing paths.

 Multi-point LDP (mLDP) refers to extensions in LDP to setup multi-
 point LSPs, point-to-multipoint (P2MP) or multipoint-to-multipoint
 (MP2MP), by means of set of extensions and procedures defined in
 [RFC6388]. In order to work in an MTR setup to take advantage of
 MTs, it is a natural extension to make mLDP become MT-aware. This
 document specifies the extensions to mLDP to support IGP Multi-
 Topology Routing (MTR).

 Conventions used in this document

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



Wijnands, et. al            Expires July 2012                  [Page 3]


Internet-Draft mLDP Extensions for Multi-Topology Routing  January 2012


   In this document, these words will appear with that interpretation
   only when in ALL CAPS. Lower case uses of these words are not to be
   interpreted as carrying RFC-2119 significance.

4. MT-Scoped mLDP FECs

   As defined in [MT-LDP], the Multi-Topology Identifier (MT-ID) is an
   identifier that is used to associate an LSP with a certain MTR
   topology. In the context of MP LSPs, this identifier is part of the
   mLDP FEC encoding so that LDP peers are able to setup an MP LSP via
   their own defined MTR policy. In order to avoid conflicting MTR
   policies for the same mLDP FEC, the MT-ID needs to be a part of the
   FEC, so that different MT-ID values will result in unique MP-LSP FEC
   elements.

   Since the MT-ID is part of the FEC, it will apply to all the LDP
   messages that potentially include an mLDP FEC element.

4.1. MP FEC Extensions for MT

   Following subsections propose the extensions to bind an mLDP FEC to
   a topology. The mLDP MT extensions reuse some of the extensions
   specified in [MT-LDP].

4.1.1. MP FEC Element

   Base mLDP specification [RFC6388] defines MP 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | MP FEC type   |    AF (IP/IPv6)               |    AF Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Root Node Address                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Opaque Length              |       Opaque Value ...        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 1: MP FEC Element Format [RFC6388]


   Where "Root Node Address" encoding is as defined for given "Address
   Family", and whose length (in octets) is specified by the "AF
   Length" field.



Wijnands, et. al            Expires July 2012                  [Page 4]


Internet-Draft mLDP Extensions for Multi-Topology Routing  January 2012


   To extend MP FEC elements for MT, the MT-ID is an identifier that is
   relevant in the context of the root address of the MP LSP. The MT-ID
   identifier determines in which topology the root address needs to be
   resolved. Since the MT-ID should be considered part of the mLDP FEC,
   the most natural place to encode the MT-ID is as part of the root
   address. To encode MT-ID as part of the root address, we are
   proposing to use MT IP Address Families as described in following
   sub section.

4.1.2. MT IP Address Families

   [MT-LDP] specification proposes new address families, named "MT IP"
   and "MT IPv6", to allow specification of an IP prefix within a
   topology scope. The Figure 2 of [MT-LDP] specification defines the
   format of the data associated with these new Address Families 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     (IP) Prefix                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Reserved             |        MT-ID                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


           Figure 2: MT IP Address Families Data Format [MT-LDP]


   Where "(IP) Prefix" is an IPv4 and IPv6 address for "MT IP" and "MT
   IPv6" AF respectively.

4.1.3. MT MP FEC Element

   We extend MP FEC Element for MT by using MT IP Address Family (and
   its associated MT-ID) in a MP FEC Element. The resultant MT MP FEC
   element will be encoded as follows:












Wijnands, et. al            Expires July 2012                  [Page 5]


Internet-Draft mLDP Extensions for Multi-Topology Routing  January 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | MP FEC type   |  AF (MT IP/ MTIPv6)           |    AF Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Root Node Address                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Reserved             |        MT-ID                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Opaque Length              |       Opaque Value ...        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 3: MT-Scoped MP FEC Element Format


   In the context of this document, the applicable LDP FECs for MT mLDP
   include:

   o  MP FEC Elements:

       o P2MP (type 0x6)

       o MP2MP Upstream (type 0x7)

       o MP2MP Downstream (type 0x8)

   o  Typed Wildcard FEC Element(type 0x5)

   In case of "Typed Wildcard FEC Element", the sub FEC Element type
   MUST be one of the MP FECs listed above.

   This specification allows the use of Topology-scoped mLDP FECs in
   LDP label and notification messages, as applicable.

4.2. Topology IDs

   This document assumes the same definitions and procedures associated
   with MT-ID as defined in [MT-LDP] specification.

5. Multipoint MT Capability

   "Multipoint MT Capability" is a new LDP capability, defined in
   accordance with LDP Capability definition guidelines [RFC5561], that
   is to be advertised to its peers by an mLDP speaker to announce its
   capability to support MTR and the procedures specified in this


Wijnands, et. al            Expires July 2012                  [Page 6]


Internet-Draft mLDP Extensions for Multi-Topology Routing  January 2012


   document. This capability MAY be sent either in an Initialization
   message at the session establishment time, or in a Capability
   message dynamically during the lifetime of a session (only if
   "Dynamic Announcement" capability [RFC5561] has been successfully
   negotiated with the peer).

   The format of this capability 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|  Multipoint MT Cap.(IANA) |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |S| Reserved    |
   +-+-+-+-+-+-+-+-+

              Figure 4: "Multipoint MT Capability" TLV Format


   Where:

     U- and F-bits: MUST be 1 and 0, respectively, as per Section 3 of
     LDP Capabilities [RFC5561].

     Multipoint MT: TLV type (IANA assigned).

     Length: The length (in octets) of TLV. The value of this field
     MUST be 1 as there is no Capability-specific data [RFC5561] that
     follows in the TLV.

     S-bit: MUST be 1 if used in LDP Initialization message. MAY be
     set to 0 or 1 in dynamic LDP Capability message to advertise or
     withdraw the capability respectively.

   An mLDP speaker that has successfully advertised and negotiated
   "Multipoint MT" capability MUST support the following:

     1. Topology-scoped mLDP FECs in LDP messages ( Section 4.1. )
     2. Topology-scoped mLDP forwarding setup ( Section 7. )

6. MT Applicability on FEC-based features

6.1. MT Typed Wildcard MP FEC Elements

   RFC5918 extends base LDP and defines Typed Wildcard FEC Element
   framework [RFC5918]. Typed Wildcard FEC element can be used in any


Wijnands, et. al            Expires July 2012                  [Page 7]


Internet-Draft mLDP Extensions for Multi-Topology Routing  January 2012


   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 support [RFC5918], and
   these procedures apply as-is to Multipoint MT FEC wildcarding. Like
   Typed Wildcard MT Prefix FEC Element, as defined in [MT-LDP], the MT
   extensions allow use of "MT IP" or "MT IPv6" in the Address Family
   field of the Typed Wildcard MP FEC element in order to use wildcard
   operations in the context of a given topology as identified by MT-ID
   field.

   This document proposes following format and encoding for a Typed
   Wildcard MP FEC element:

    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)| Type = MP FEC |   Len = 6     |  AF = MT IP ..|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |... or MT IPv6 |         Reserved              |    MT ID      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |MT ID (contd.) |
   +-+-+-+-+-+-+-+-+

             Figure 5: "Typed Wildcard MP FEC Element" for MT

   Where:

   Type: One of MP FEC Element type (P2MP, MP2MP Upstream, MP2MP
   Downstream).

   The proposed format allows an LSR to perform wildcard MP FEC
   operations under the scope of a topology.

6.2. MT End-of-LIB

   [RFC5919] specifies extensions and procedures that allows an LDP
   speaker to signal its End-of-LIB (i.e. convergence) for a given FEC
   type towards a peer. MT extensions for MP FEC do not require any
   change in these procedures and they apply as-is to MT MP FEC
   elements. This means that an MT mLDP speaker MAY signal its
   convergence per topology using MT Typed Wildcard MP FEC element.






Wijnands, et. al            Expires July 2012                  [Page 8]


Internet-Draft mLDP Extensions for Multi-Topology Routing  January 2012


7. Topology-Scoped Forwarding

   Since the MT-ID is part of the mLDP FEC, there is no need to support
   the concept of multiple topology tables in mLDP. Each MP LSP will be
   unique due to the MT-ID being part of the FEC. There is also no need
   to have specific Label Forwarding Tables per topology. Each MP LSP
   will have its own unique local label in the LFT. In order to satisfy
   the MTR in mLDP, the upstream LSR and downstream forwarding
   interface procedures must be changed.

7.1. Upstream LSR selection

   The procedures as described in RFC-6388 section 2.4.1.1
   depend on the best path to reach the root. When the MT-ID is
   signaled as part of the FEC, the MT-ID is used to select the
   topology that must to be used to find the best path to the root
   address. Using the next-hop from this best path, a LDP peer is
   selected following the procedures as defined in [RFC6388].

7.2. Downstream forwarding interface

   The procedures as described in RFC-6388 section-2.4.1.2
   describe how a downstream forwarding interface is selected.
   In these procedures any interface leading to the downstream LDP
   neighbor can be considered as candidate forwarding interface. When
   the MT-ID is part of the FEC, this is no longer true. An interface
   must only be selected if it is part of the same topology that was
   signaled in the mLDP FEC element. Besides this restriction, the
   other procedures in [RFC6388] apply.

8. Security Considerations

   This extension to mLDP does not introduce any new security
   considerations beyond that already apply to the base LDP
   specification [RFC5036], base mLDP specification [RFC6388], and MPLS
   security framework [RFC5920].

9. IANA Considerations

  The document introduces following new protocol element that requires
  IANA consideration and code point assignment:





Wijnands, et. al            Expires July 2012                  [Page 9]


Internet-Draft mLDP Extensions for Multi-Topology Routing  January 2012


   o  New LDP Capability TLV: "Multipoint MT Capability" TLV (requested
      code point: 0x511 from LDP registry "TLV Type Name Space")

10. References

10.1. Normative References

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

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

   [RFC5120] T. Przygienda, Z2 Sagl, N. Shen, N., "M-ISIS: Multi-
             Topology Routing in IS-IS", RFC 5120, February 2008.

   [MT-LDP]  Q. Zhao, L. Fang, C. Zhou, L. Li, N. So, R. Torvi, "LDP
             Extension for Multiple Topology Support", draft-ietf-mpls-
             ldp-multi-topology-02, Work in progress, November 2011.

   [RFC6388] I. Minei, I. Wijnand, K. Kompella, B., "LDP Extensions for
             P2MP and MP2MP LSPs", RFC 6388, November 2011.

   [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and Le
             Roux, JL., "LDP Capabilities", RFC 5561, July 2009.

10.2. Informative References

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

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

   [RFC5918] Asati, R., Minei, I., and Thomas, B. "Label Distribution
             Protocol Typed Wildcard FEC", RFC 5918, August 2010.

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

11. Acknowledgments

   The authors would like to acknowledge Eric Rosen for his input on
   this specification.

   This document was prepared using 2-Word-v2.0.template.dot.



Wijnands, et. al            Expires July 2012                 [Page 10]


Internet-Draft mLDP Extensions for Multi-Topology Routing  January 2012


   Authors' Addresses

   IJsbrand Wijnand
   Cisco Systems, Inc.
   De kleetlaan 6a,
   Diegem  1831 Belgium.
   Email: ice@cisco.com


   Kamran Raza
   Cisco Systems, Inc.
   2000 Innovation Drive,
   Ottawa, Ontario K2K-3E8, Canada.
   Email: skraza@cisco.com



































Wijnands, et. al            Expires July 2012                 [Page 11]