One document matched: draft-kompella-mpls-multiarea-te-00.txt

Network Working Group                              Kireeti Kompella
Internet Draft                                     Juniper Networks
Expiration Date: May 2001                             Yakov Rekhter
                                                      Cisco Systems



                  Multi-area MPLS Traffic Engineering

                draft-kompella-mpls-multiarea-te-00.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 except that the right to
   produce derivative works is not granted.

   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

   An ISIS/OSPF routing domain may consists of multiple areas. This
   document postulates a set of mechanisms, and then outlines how these
   mechanisms could be used to establish/maintain Traffic Engineering
   LSPs that span multiple areas.  The procedures outlined in this
   document for establishing such LSPs do not require
   aggregation/abstraction of the TE information.








draft-kompella-mpls-multiarea-te-00.txt                         [Page 1]

Internet Draft   draft-kompella-mpls-multiarea-te-00.txt   November 2000


3. Set of mechanisms

   In this section we postulate a set of mechanisms that could be used
   to construct LSPs that span multiple ISIS/OSPF areas. The actual
   application of these mechanisms to construct such LSPs is covered in
   the next section. We assume that the mechanisms listed below are
   either already available, or could be realized via extensions to the
   existing signaling (RSVP/CR-LDP) and/or routing (ISIS/OSPF) protocols
   used for MPLS Traffic Engineering.


3.1. Passing constraints

   An LSR that acts as a head-end of an LSP should be able to pass the
   constraints associated with this LSP to some other node. The other
   node may, or may not be along the path taken by the LSP. A way to
   provide this functionality is described in [Kompella].


3.2. Loose hops

   An LSR should be able to specify loose ERO hops, and let some
   intermediate LSR(s) along the path to expand it to strict hops. Note
   that the ability to specify loose hops is already available.


3.3. Path computation server

   An LSR that originates an LSP should be able to "ask" some other node
   to compute the path for the LSP. The node that computes the path may,
   or may not be along the path taken by the LSP. The node may compute
   either the whole path, or a segment of the path. In the latter case
   the computed path would include loose hops. This mechanism requires
   the ability of the LSR that originates the LSP to pass the
   constraints associated with that LSP to the node that is going to
   compute the path for the LSP. It also requires the ability of the LSR
   that originates the LSP to pass the address of LSR at the tail-end of
   the LSP to the node that is going to compute the path for the LSP,
   and for the node that is going to compute the path for the LSP the
   ability to pass back to the node that originates the LSP the ERO that
   contains the results of the path computation.










draft-kompella-mpls-multiarea-te-00.txt                         [Page 2]

Internet Draft   draft-kompella-mpls-multiarea-te-00.txt   November 2000


3.4. Acquiring topology/resources information for multiple areas

   A node should be able to obtain the topology and TE information of
   not just its own area, but other areas as well. This information may
   be subject to filtering (e.g., the node could obtain only the
   information about FAs in other areas). The node should be able to
   perform Constrained SPF (CSPF) based on this information.

   An (existing) example of a node that has the topology and TE
   information for several areas is an OSPF Area Border Router (ABR) -
   an ABR has the topology and TE information for the backbone area,
   plus all the other areas connected to that ABR.

   An extreme case is when a node obtains the topology and TE
   information of the whole OSPF/ISIS domain.


4. Constructing multi-area TE LSPs

   Consider the situation where the head-end of a TE LSP is in a
   different ISIS/OSPF area than the tail-end of a TE LSP. We'll refer
   to the area that the head-end is in as the head-end area.  We'll
   refer to the area that the tail-end is in as the tail-end area.

   Given the set of the mechanisms outlined in the previous section, the
   following sub-sections outline some of the possible scenarios that
   use these mechanisms in order to construct TE LSPs that span multiple
   OSPF/ISIS areas.


4.1. Scenario 1

   Path computation is done on a per area basis. The head-end LSR
   computes strict hops within its own area. The head-end LSR then
   initiates LSP path setup. The setup includes the information about
   the constraints associated with the LSP.

   The ABR in the head-end area uses the topology and TE information of
   the backbone area, as well as the information about the constraints
   associated with the LSP (the ABR receives this information as part of
   the LSP setup) to compute strict hops within the backbone area to the
   ABR in the tail-end area.

   The ABR in the tail-end area uses the topology and TE information of
   the tail-end area, as well as the information about the constraints
   associated with the LSP (the ABR receives this information as part of
   the LSP setup) to compute strict hops within the tail-end area from
   itself to the tail-end LSR.



draft-kompella-mpls-multiarea-te-00.txt                         [Page 3]

Internet Draft   draft-kompella-mpls-multiarea-te-00.txt   November 2000


   Note that since the choice of ABR in the head-end area is determined
   by only the information in the head-end area, the inability to find a
   route across multiple areas doesn't mean that the route doesn't exist
   - it may mean that another ABR in the head-end area should be chosen,
   and/or it may mean than another ABR in the tail-end area should be
   chosen.  Thus the failure to find a route may require to try another
   ABRs. The total number of such attempts could be as large as H*T
   (where H is the number of ABRs in the head-end area, and T is the
   number of ABRs in the tail-end area).

   Handling link/node failures could be done a two-phase approach, where
   in the first phase a failure is handled within an area where the
   failure occurs, and only if that fails, the head-end LSR is notified
   of the failure and is expected to handle it.

   In this scenario the only information that has to be distributed
   across area boundaries are the reachability information associated
   with routers' interface addresses (including loopback addresses, if
   an LSP is to be terminated on a router loopback address). Both OSPF
   and ISIS already provide mechanisms to accomplish this.


4.2. Scenario 2

   The head-end LSR requests an ABR in its (head-end) area to compute
   the path all the way from the LSR to the ABR in the destination area.
   This is possible because the ABR in the head-end area maintains the
   topology and resource information both for the head-end area and for
   the backbone area.  The ABR in the destination area then computes the
   rest of the path.

   Note that the ABR in the source area that computes the path all the
   way to the ABR in the destination area may, or may not be on the path
   taken by the LSP.

   In this scenario the only information that has to be distributed
   across area boundaries are the reachability information associated
   with routers' interface addresses (including loopback addresses, if
   an LSP is to be terminated on a router loopback address). Both OSPF
   and ISIS already provide mechanisms to accomplish this.


4.3. Scenario 3

   The head-end LSR obtains the TE information from the backbone area,
   and uses it to compute the path all the way to the ABR in the tail-
   end area. The ABR in the tail-end area computes the rest of the path.




draft-kompella-mpls-multiarea-te-00.txt                         [Page 4]

Internet Draft   draft-kompella-mpls-multiarea-te-00.txt   November 2000


   If the head-end area contains LSRs that don't originate LSPs, then
   these LSRs need not maintain the TE information from the backbone
   area.


4.4. Scenario 4

   The head-end LSR requests an entity that has the entire network (all
   areas) topology to compute the whole path.

   Except for the entity that has the entire network topology, in this
   scenario the only information that has to be distributed across area
   boundaries are the reachability information associated with routers'
   interface addresses (including loopback addresses, if an LSP is to be
   terminated on a router loopback address). Both OSPF and ISIS already
   provide mechanisms to accomplish this.


5. Pre-engineered backbone area

   In certain cases it may be desirable to "pre-engineer" the backbone
   area by constructing a set of TE LSPs that would be used as FAs by
   the traffic that has to traverse the backbone area. The scenarios
   outline above do not preclude this as an option.

   With a pre-engineered backbone area, a variation of Scenario 3 would
   be to restrict the backbone information leaked to the non-backbone
   areas to only the information associated with the FAs in the backbone
   area.


6. Aggregation/abstraction/summarization of TE information

   The procedures outlined in this document for establishing multi-area
   TE LSPs do not require aggregation/abstraction of the TE information
   for the purpose of re-advertising this information across area
   boundaries.














draft-kompella-mpls-multiarea-te-00.txt                         [Page 5]

Internet Draft   draft-kompella-mpls-multiarea-te-00.txt   November 2000


7. Security Considerations

   Security issues are not discussed in this document.


8. Acknowledgements

   We would like to thank Noel Chiappa, Tony Li, Robert Raszuk, and Alex
   Zinin for helping us with the ideas presented in this document.


9. References

   [Kompella] Kompella, K., "Carrying Constraints in RSVP"


10. Author Information


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

Yakov Rekhter
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134






















draft-kompella-mpls-multiarea-te-00.txt                         [Page 6]