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

Versions: 00 01 02 03 04 05 06 07 08 RFC 4206

Network Working Group                             Kireeti Kompella
Internet Draft                                    Juniper Networks
Expiration Date: August 2001                         Yakov Rekhter
                                                  Juniper Networks


                       LSP Hierarchy with MPLS TE

                  draft-ietf-mpls-lsp-hierarchy-02.txt


1. Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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.


2. Abstract

   To improve scalability of MPLS TE it may be useful to aggregate TE
   LSPs.  The aggregation is accomplished by (a) an LSR creating a TE
   LSP, (b) the LSR forming a forwarding adjacency out of that LSP
   (advertising this LSP as a link into ISIS/OSPF), (c) allowing other
   LSRs to use forwarding adjacencies for their path computation, and
   (d) nesting of LSPs originated by other LSRs into that LSP (by using
   the label stack construct).

   This document describes the mechanisms to accomplish this.







draft-ietf-mpls-lsp-hierarchy-03.txt                            [Page 1]

Internet Draft    draft-ietf-mpls-lsp-hierarchy-03.txt     February 2001


3. Overview

   An LSR uses MPLS TE procedures to create and maintain an LSP.  The
   LSR then may (under its local configuration control) announce this
   LSP as a Traffic Engineering (TE) link into ISIS/OSPF.  We call such
   a link a "forwarding adjacency".  We refer to the LSP as the
   "forwarding adjacency LSP", or just FA-LSP.

   In general, creation/termination of a forwarding adjacency and its
   FA-LSP could be driven either by mechanisms outside of MPLS (e.g.,
   via configuration control on the LSR at the head-end of the
   adjacency), or by mechanisms within MPLS (e.g., as a result of the
   LSR at the head-end of the adjacency receiving LSP setup requests
   originated by some other LSRs).

   ISIS/OSPF floods the information about forwarding adjacencies just as
   it floods the information about any other links.  As a result of this
   flooding, an LSR has in its TE link state database the information
   about not just conventional links, but forwarding adjacencies as
   well.

   An LSR, when performing path computation, uses not just conventional
   links, but forwarding adjacencies as well.  Once a path is computed,
   the LSR uses RSVP/CR-LDP for establishing label binding along the
   path.

   In this document we define mechanisms/procedures to accomplish the
   above.  These mechanisms/procedures cover both the routing
   (ISIS/OSPF) and the signalling (RSVP/CR-LDP) aspects.

   Note that an LSP may be advertised as a point-to-point link into ISIS
   or OSPF, to be used in normal SPF by nodes other than the head end.
   While this is similar in spirit to a Forwarding Adjacency, this is
   beyond the scope of this document.


4. Routing aspects

   In this section we describe procedures for constructing forwarding
   adjacencies out of LSPs, and handling of forwarding adjacencies by
   ISIS/OSPF.  Specifically, this section describes how to construct the
   information needed to advertise LSPs as links into ISIS/OSPF.
   Procedures for creation/termination of such LSPs are defined in
   Section 6.

   Forwarding adjacencies may be represented as either unnumbered or
   numbered links.  If FAs are numbered, the local and remote IPv4
   addresses come out of a /31; the local address is the one specified



draft-ietf-mpls-lsp-hierarchy-03.txt                            [Page 2]

Internet Draft    draft-ietf-mpls-lsp-hierarchy-03.txt     February 2001


   as the IPv4 tunnel sender address; the remote address can then be
   inferred.  If the LSP is bidirectional, the tail-end can thus know
   the addresses to assign to the reverse FA.

   If there are multiple LSPs that all originate on one LSR and all
   terminate on another LSR, then at one end of the spectrum all these
   LSPs could be merged (under control of the head-end LSR) into a
   single forwarding adjacency using the concept of Link Bundling (see
   [BUNDLE]), while at the other end of the spectrum each such LSP could
   be advertised as its own adjacency.

   When a forwarding adjacency is created under administrative control
   (static provisioning), the attributes of the FA-LSP have to be
   provided via configuration.  Specifically, the following attributes
   may be configured for the FA-LSP: the head-end address (if left
   unconfigured, this defaults to the head-end LSR's Router ID); the
   tail-end address; bandwidth and resource colors constraints.  The
   path taken by the FA-LSP may be either computed by the LSR at the
   head-end of the FA-LSP, or specified by explicit configuration; this
   choice is determined by configuration.

   When a forwarding adjacency is created dynamically, the attributes of
   its FA-LSP are inherited from the LSP which induced its creation.
   Note that the bandwidth of the FA-LSP must be at least as big as the
   LSP that induced it, but may be bigger if only discrete bandwidths
   are available for the FA-LSP.  In general, for dynamically
   provisioned forwarding adjacencies, a policy-based mechanism may be
   needed to associate attributes to the FA-LSPs.


4.1. Traffic Engineering parameters

   In this section, the Traffic Engineering parameters (see [OSPF-TE]
   and [ISIS-TE]) for forwarding adjacencies are described.


4.1.1. Link type (OSPF only)

   The Link Type of a forwarding adjacency is set to "point-to-point".


4.1.2. Link ID (OSPF only)

   The Link ID is set to the Router ID of the tail end of FA-LSP.







draft-ietf-mpls-lsp-hierarchy-03.txt                            [Page 3]

Internet Draft    draft-ietf-mpls-lsp-hierarchy-03.txt     February 2001


4.1.3. Local and remote interface IP address

   If the FA is to be numbered, the local interface IP address (OSPF) or
   IPv4 interface address (ISIS) is set to the head-end address of the
   FA-LSP.  The remote interface IP address (OSPF) or IPv4 neighbor
   address (ISIS) is set to the tail-end address of the FA-LSP.


4.1.4. Outgoing and Incoming Interface Identifiers

   If the FA has been assigned a 32-bit interface identifier (see
   [UNNUM-RSVP], [UNNUM-CRLDP]), this identifier MUST be unique within
   the scope of the advertising LSR; i.e., this identifier MUST be
   different from interface identifiers assigned to other interfaces,
   component links and bundles (see [BUNDLE]).  In this case, the
   Outgoing Interface Identifier is set to the assigned interface
   identifier (see [GMPLS-ISIS] and [GMPLS-OSPF]).  If the underlying
   FA-LSP for this FA is bidirectional, then the Incoming Interface
   Identifier (learned via the signalling protocol for the FA-LSP; see
   [UNNUM-RSVP], [UNNUM-CRLDP]) is set to the interface identifier
   assigned by the tail end to the reverse FA-LSP.  Otherwise, the
   Incoming Interface Identifier is set to 0.

   Note that if an interface identifier is assigned, it MUST be sent to
   the tail end of the FA-LSP via the signalling protocol used to set up
   the FA-LSP (see [UNNUM-RSVP], [UNNUM-CRLDP]).


4.1.5. Traffic Engineering metric

   By default the TE metric on the forwarding adjacency is set to max(1,
   (the TE metric of the FA-LSP path) - 1) so that it attracts traffic
   in preference to setting up a new LSP.  This may be overridden via
   configuration at the head-end of the forwarding adjacency.


4.1.6. Maximum bandwidth

   By default the maximum reservable bandwidth and the initial maximum
   LSP bandwidth for all priorities of the forwarding adjacency is set
   to the bandwidth of the FA-LSP.  These may be overridden via
   configuration at the head-end of the forwarding adjacency (note that
   the maximum LSP bandwidth at any one priority should be no more than
   the bandwidth of the FA-LSP).







draft-ietf-mpls-lsp-hierarchy-03.txt                            [Page 4]

Internet Draft    draft-ietf-mpls-lsp-hierarchy-03.txt     February 2001


4.1.7. Unreserved bandwidth

   The initial unreserved bandwidth for all priority levels of the
   forwarding adjacency is set to the bandwidth of the FA-LSP.


4.1.8. Resource class/color

   By default, a forwarding adjacency does not have resource colors
   (administrative groups).  This may be overridden by configuration at
   the head-end of the forwarding adjacency.


4.1.9. Link Multiplex Capability

   The Link Multiplex Capability (see Section 7.1) associated with the
   forwarding adjacency is the Link Multiplex Capability of the last
   link in the FA-LSP.


4.1.10. Path information

   A forwarding adjacency advertisement could contain the information
   about the path taken by the FA-LSP associated with that forwarding
   adjacency. This information may be used for path calculation by other
   LSRs. This information is carried in the Path TLV.  In both IS-IS and
   OSPF, this TLV is encoded as follows: the type is TBD, the length is
   4 times the path length, and the value is a list of 4 octet IPv4
   addresses identifying the links in the order that they form the path
   of the forwarding adjacency.

   It is possible that the underlying Path information might change over
   time, via configuration updates, or dynamic route modifications,
   resulting in the change of the Path TLV.

   If forwarding adjacencies are bundled (via link bundling), and if the
   resulting bundled link carries a Path TLV, it MUST be the case that
   the underlying path followed by each of the FA-LSPs that form the
   component links is the same.












draft-ietf-mpls-lsp-hierarchy-03.txt                            [Page 5]

Internet Draft    draft-ietf-mpls-lsp-hierarchy-03.txt     February 2001


5. Other considerations

   It is expected that forwarding adjacencies will not be used for
   establishing ISIS/OSPF peering relation between the routers at the
   ends of the adjacency.

   It may be desired in some cases that forwarding adjacencies only be
   used in Traffic Engineering path computations.  In IS-IS, this can be
   accomplished by setting the default metric of the extended IS
   reachability TLV for the FA to the maximum link metric (2^24 - 1).
   In OSPF, this can be accomplished by not advertising the link as a
   regular LSA, but only as a TE opaque LSA.

   Since LSPs are in general unidirectional, it follows that forwarding
   adjacencies are (by definition) unidirectional links.  Therefore, the
   TE path computation procedures should not perform two-way
   connectivity check on the links used by the procedures.


6. Controlling FA-LSPs boundaries

   To facilitate controlling the boundaries of FA-LSPs this document
   introduces two new mechanisms: Link Multiplex Capability, and "LSP
   region" (or just "region").


6.1. Link Multiplex Capability sub-TLV

   Associated with each link (including forwarding adjacencies) is a new
   attribute - Link Multiplex Capability.  In this section we define the
   Link Multiplex Capability sub-TLV and describe the various values it
   can take.

   A network may have links with different multiplexing/demultiplexing
   capabilities.  For example, a node may not be able to demultiplex
   individual packets on a given link, but it may be able to multiplex/
   demultiplex channels within a SONET payload.  The Link Multiplex
   Capability sub-TLV identifies the associated
   multiplexing/demultiplexing capability of a link.  If there is no
   Link Multiplex Capability attribute for a link, the link is assumed
   to be packet-switch capable (PSC-1).

   In ISIS the Link Multiplex Capability is a sub-TLV of the extended IS
   reachability TLV (type 22) as defined in [ISIS-TE].  The type of the
   Link Multiplex Capability sub-TLV is 19.  The length of the TLV is
   one octet.  The value field of the sub-TLV contains the Link
   Multiplex Capability, encoded as follows:




draft-ietf-mpls-lsp-hierarchy-03.txt                            [Page 6]

Internet Draft    draft-ietf-mpls-lsp-hierarchy-03.txt     February 2001


       Value         Link Multiplex Capabilities
           1         Packet-Switch Capable-1 (PSC-1)
           2         Packet-Switch Capable-2 (PSC-2)
           3         Packet-Switch Capable-3 (PSC-3)
           4         Packet-Switch Capable-4 (PSC-4)
          51         Layer-2 Switch Capable  (L2SC)
         100         Time-Division-Multiplex Capable (TDM)
         150         Lambda-Switch Capable   (LSC)
         200         Fiber-Switch Capable    (FSC)

   In the OSPF Traffic Engineering LSA, the Link Multiplex Capability is
   a sub-TLV of the Link TLV as defined in [OSPF-TE], with type 10 and
   length of four octets.  The value field is taken from the above list.
   The format of the Link Multiplex Capability sub-TLV is as shown in
   the next figure.

   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |              11               |            Length             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Link Mux Cap. |                  Reserved                     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   If a link is of type L2SC, that means that the node receiving layer 2
   frames over this link can switch the received frames based on the
   layer 2 address.  For example, a link terminating on an ATM switch
   would be considered L2SC.

   If a link is of type PSC-1 through PSC-4, that means that the node
   receiving data over this link can demultiplex (switch) the received
   data on a packet-by-packet basis.  The various levels of PSC
   establish a hierarchy of LSPs tunneled within LSPs.

   If a link is of type TDM, that means that the node receiving data
   over this link can multiplex or demultiplex channels within a
   SONET/SDH payload.

   If a link is of type LSC, that means that the node receiving data
   over this link can recognize and switch individual lambdas within the
   link (fiber).

   If a link is of type FSC, that means that the node receiving data
   over this link (fiber) can switch the entire contents to another link
   (fiber) (without distinguishing lambdas, channels or packets).

   Note that the node that is advertising a given link (i.e., the node



draft-ietf-mpls-lsp-hierarchy-03.txt                            [Page 7]

Internet Draft    draft-ietf-mpls-lsp-hierarchy-03.txt     February 2001


   that is transmitting) needs to know the multiplex/demultiplex
   capabilities at the other end of the link (i.e., the receiving end of
   the link).  One way to accomplish this is through configuration.
   Other options to accomplish this are outside the scope of this
   document.


6.2. LSP regions

   The information carried in the Link Multiplex Capabilities is used to
   construct LSP regions, and determine regions' boundaries as follows.

   Define an ordering among link mux capabilities as follows: PSC-1 <
   PSC-2 < PSC-3 < PSC-4 < TDM < LSC < FSC.  Given two links link-1 and
   link-2 with link mux capabilities lmc-1 and lmc-2 respectively, say
   that link-1 < link-2 iff lmc-1 < lmc-2 or lmc-1 == lmc-2 == TDM, and
   link-1's bandwidth is less than link-2's switching speed.

   Suppose an LSP's path is as follows: node-0, link-1, node-1, link-2,
   node-2, ..., link-n, node-n.  If link-i < link-(i+1), we say that the
   LSP has crossed a region boundary at node-i; with respect to that LSP
   path, the LSR at node-i is an edge LSR.  The 'other edge' of the
   region with respect to the LSP path is node-k, where k is the
   smallest number greater than i+1 such that link-k <= link-i.

   Path computation may take into account region boundaries when
   computing a path for an LSP.  For example, path computation may
   restrict the path taken by an LSP to only the links whose Link
   Multiplex Capability is PSC-1.


7. Signalling aspects

   In this section we describe procedures that an LSR at the head-end of
   a forwarding adjacency uses for handling LSP setup originated by
   other LSR.

   As we mentioned before, establishment/termination of FA-LSPs may
   triggered either by mechanisms outside of MPLS (e.g., via
   administrative control), or by mechanisms within MPLS (e.g., as a
   result of the LSR at the edge of an aggregate LSP receiving LSP setup
   requests originated by some other LSRs beyond LSP aggregate and its
   edges).  Procedures described in Section 7.1 applied to both cases.
   Procedures described in Section 7.2 apply only to the latter case.







draft-ietf-mpls-lsp-hierarchy-03.txt                            [Page 8]

Internet Draft    draft-ietf-mpls-lsp-hierarchy-03.txt     February 2001


7.1. Common procedures

   For the purpose of processing the ERO in a Path/Request message of an
   LSP that is to be tunneled over a forwarding adjacency, an LSR at the
   head-end of the FA-LSP views the LSR at the tail of that FA-LSP as
   adjacent (one IP hop away).

   If the Link Multiplex Capability of the FA-LSP is PSC[1-4], the
   Path/Request message for the tunneled LSP MUST be tunneled over the
   FA-LSP.  If the encapsulation on the carrier LSP can distinguish IP
   from MPLS, the Path/Request message is sent as a plain IP packet.
   Otherwise, the Path/Request message is sent with a label of 0,
   meaning "pop the label and treat as IP".

   If the Link Multiplex Capability of the FA-LSP is not PSC[1-4], the
   Path message is unicast over the control plane to the tail of the
   carrier LSP, without the Router Alert option.  The whole Path
   message, including IP header, MAY also be encapsulated in another IP
   header whose destination IP address matches the tail's IP address.

   The Resv/Mapping message back to the head-end of the FA-LSP (PHOP)
   cannot be sent over the same FA-LSP as it is unidirectional.  The
   Resv/Mapping message can either take any packet-switch capable LSP
   whose end-point is the head-end of the FA-LSP, or be unicast over the
   control plane to the head-end.  RSVP Resv Messages MAY be
   encapsulated in another IP header whose destination IP address
   matches the head-end's IP address.

   When an LSP is tunneled through an FA-LSP, the LSR at the head-end of
   the FA-LSP subtracts the LSP's bandwidth from the unreserved
   bandwidth of the forwarding adjacency.

   In the presence of link bundling (when link bundling is applied to
   forwarding adjacencies), when an LSP is tunneled through an FA-LSP,
   the LSR at the head-end of the FA-LSP also need to adjust Max LSP
   bandwidth of the forwarding adjacency.


7.2. Specific procedures

   When an LSR receives a Path/Request message, the LSR determines
   whether it is at the edge of a region with respect to the ERO carried
   in the message.  The LSR does this by looking up the link mux
   capabilities of the previous hop and the next hop in its IGP
   database, and comparing them using the relation defined in Section
   7.2.  If the LSR is not at the edge of a region, the procedures in
   this section do not apply.




draft-ietf-mpls-lsp-hierarchy-03.txt                            [Page 9]

Internet Draft    draft-ietf-mpls-lsp-hierarchy-03.txt     February 2001


   If the LSR is at the edge of a region, it must then determine the
   other edge of the region with respect to the ERO, again using the IGP
   database.  The LSR then extracts the strict hop subsequence from
   itself to the other end of the region.

   The LSR then compares the strict hop subsequence with all existing
   FA-LSPs originated by the LSR; if a match is found, that FA-LSP has
   enough unreserved bandwidth for the LSP being signaled, and the L3PID
   of the FA-LSP is compatible with the L3PID of the LSP being signaled,
   the LSR uses that FA-LSP as follows.  The Path/Request message for
   the original LSP is sent to the egress of the FA-LSP, not to the next
   hop along the FA- LSP's path.  The PHOP in the message is the address
   of the LSR at the head-end of the FA-LSP.  Before sending the
   Path/Request message, the ERO in that message is adjusted by removing
   the subsequence of the ERO that lies in the FA-LSP, and replacing it
   with just the end point of the FA-LSP.

   Otherwise (if no existing FA-LSP is found), the LSR sets up a new FA-
   LSP.  That is, it initiates  a new LSP setup just for the FA-LSP.

   After the LSR establishes the new FA-LSP, the LSR announces this LSP
   into IS-IS/OSPF as a forwarding adjacency.

   The unreserved bandwidth of the forwarding adjacency is computed by
   subtracting the bandwidth of sessions pending the establishment of
   the FA-LSP associated from the bandwidth of the FA-LSP.

   An FA-LSP could be torn down by the LSR at the head-end of the FA-LSP
   as a matter of policy local to the LSR.  It is expected that the FA-
   LSP would be torn down once there are no more LSPs carried by the FA-
   LSP.  When the FA-LSP is torn down, the forwarding adjacency
   associated with the FA-LSP is no longer advertised into IS-IS/OSPF.


7.3. FA-LSP Holding Priority

   The value of the holding priority of an FA-LSP must be the minimum of
   the configured holding priority of the FA-LSP and the holding
   priorities of the LSPs tunneling through the FA-LSP (note that
   smaller priority values denote higher priority).  Thus, if an LSP of
   higher priority than the FA-LSP tunnels through the FA-LSP, the FA-
   LSP is itself promoted to the higher priority.  However, if the
   tunneled LSP is torn down, the FA-LSP need not drop its priority to
   its old value right away; it may be advisable to apply hysteresis in
   this case.

   If the holding priority of an FA-LSP is configured, this document
   restricts it to 0.



draft-ietf-mpls-lsp-hierarchy-03.txt                           [Page 10]

Internet Draft    draft-ietf-mpls-lsp-hierarchy-03.txt     February 2001


8. Security Considerations

   Security issues are not discussed in this document.


9. Acknowledgements

   Many thanks to Alan Hannan, whose early discussions with Yakov
   Rekhter contributed greatly to the notion of Forwarding Adjacencies.
   We would also like to thank George Swallow, Quaizar Vohra and Ayan
   Banerjee.


10. References

   [BUNDLE] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in
   MPLS Traffic Engineering", draft-kompella-mpls-bundle-05.txt (work in
   progress)

   [GMPLS-ISIS] Kompella, K., Rekhter, Y., Banerjee, A. et al, "IS-IS
   Extensions in Support of Generalized MPLS", draft-ietf-isis-gmpls-
   extensions-01.txt (work in progress)

   [GMPLS-OSPF] Kompella, K., Rekhter, Y., Banerjee, A. et al, "OSPF
   Extensions in Support of Generalized MPLS", draft-kompella-ospf-
   gmpls-extensions-01.txt (work in progress)

   [ISIS-TE] Smit, H., Li, T., "IS-IS extensions for Traffic
   Engineering", draft-ietf-isis-traffic-02.txt (work in progress)

   [OSPF-TE] Katz, D., Yeung, D., "Traffic Engineering Extensions to
   OSPF", draft-katz-yeung-ospf-traffic-04.txt (work in progress)

   [UNNUM-CRLDP] Kompella, K., Rekhter, Y., Kullberg, A., "Signalling
   Unnumbered Links in CR-LDP", draft-ietf-mpls-crldp-unnum-01.txt (work
   in progress)

   [UNNUM-RSVP] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links
   in RSVP", draft-ietf-mpls-rsvp-unnum-01.txt (work in progress)












draft-ietf-mpls-lsp-hierarchy-03.txt                           [Page 11]

Internet Draft    draft-ietf-mpls-lsp-hierarchy-03.txt     February 2001


11. Author Information


Kireeti Kompella
Juniper Networks, Inc.
1194 N. Mathilda Ave
Sunnyvale, CA 94089
e-mail: kireeti@juniper.net

Yakov Rekhter
Juniper Networks, Inc.
1194 N. Mathilda Ave
Sunnyvale, CA 94089
e-mail: yakov@juniper.net





































draft-ietf-mpls-lsp-hierarchy-03.txt                           [Page 12]


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