Internet Draft                                                June 1997

                                             Yasuhiro Katsube (Toshiba)
                                             Hiroshi Esaki (Toshiba)

    Interoperation Between Distinct Types of Label Switched Paths

           <draft-katsube-interop-between-lsps-00.txt>


Status of this memo

   This document is an Internet-Draft.  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."

   To learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).


Abstract

   Label Switching Routers are able to handle several distinct types
   of Label Switched Paths (LSPs) depending on the triggers for
   establishing or releasing LSPs or the granularity of the flow that
   are dedicated to each of the LSPs.  This memo first analyzes
   characteristics of individual types of LSPs, and discusses possible
   interoperation scenario between them.


1. Introduction

   Routers with label switching capabilities can forward L3 packets
   based on fixed length labels, e.g., VPI/VCI field in ATM, as well as
   conventional packet forwarding based on L3 address information.
   Each router manages mapping information between an incoming
   interface(s)/label(s) and an outgoing interface(s)/label(s).

   Label Switched Paths(LSPs) are largely classified into several types
   which have distinct properties from the viewpoint of; "triggers for
   establishing or releasing the LSP" and "flow granularity of the LSP".
   With regard to triggers for establishing or releasing LSPs, following
   three types would be possible;



Katsube, et al.            Expires Dec. 1997                    [Page  1]

Internet Draft        Interoperation Between LSPs              June 1997



   a. Control Traffic driven

    a1. Driven by Routing Information (Topology-driven)
          LSPs are initiated by the creation of a new routing table
          entry.

    a2. Driven by Resource Reservation Messages (Reservation-driven)
          LSPs are initiated by the reception of resource reservation
          request messages for a specific flow.

   b. Data Traffic driven (Data-driven)
          LSPs are initiated by the detection of a specific data
          packet (e.g., specific upper layers or specifig L3 addresses)
          or by the result of measurement of data traffic.


   A number of granularity levels (definition of "flow" which is allowed
   to use the LSP) would be possible such as, but not limited to;

   1. (* , egress router)            ("*" means wildcard)
   2. (* , L3_dst.prefix)
   3. (ingress router , egress router)
   4. (ingress router , L3_dst.prefix)
   5. (L3_src.prefix/host , L3_dst.prefix/host)
   6. (L3_src.host , L3_dst.host & protocol & port)


   The former classification in terms of the "trigger" and the latter
   one in terms of the "granularity" can be orthogonal in general,
   although there is some dependency between them actually.

   It is not reasonable to select only one of these alternatives but
   several (or any) of these would co-exist depending on the
   characteristics of the network or on the operational policy of the
   network.  An objective of this memo is to investigate characteristics
   of individual types of LSPs and to discuss how distinct types of
   LSPs can interoperate.

   Discussing what should the control protocol for these switched paths
   be is out of the scope of this memo.


2.  Characteristics of Each Type of LSP

   This section describes characteristics of topology-driven LSP,
   data-driven LSP, and reservation-driven LSP.





Katsube, et al.            Expires Dec. 1997                    [Page  2]

Internet Draft        Interoperation Between LSPs              June 1997


2.1  Topology-driven LSP

   Topology-driven LSPs are initiated by the creation of a new L3
   routing table entry[ARIS][RFC2105].  They can generally accommodate
   aggregated flow specified by, e.g., {ingress router, L3_dst.prefix},
   {*, L3_dst.prefix}, {ingress router, egress router}, or
   {*, egress router}.

   All packets, regardless of their higher layer information, can be
   delivered from "ingress edge routers" to "egress edge routers"
   without conventional L3 header processing in a domain.
   Since the LSPs are established according to the creation of routing
   table entries, packets don't have to wait for the LSP to be
   established each time individual packet flows are generated, which
   avoids delay for establishing LSPs as well as reduces LSP control
   overhead due to frequent establishment or release.

   The number of required LSPs at a domain depends on the aggregation
   level of LSPs, availability of multipoint-to-point LSPs (LSP merge),
   and availability of hierarchical label.  When the flow is defined by
   {ingress edge router, egress edge router} with no LSP merge assumed,
   the number of LSPs in the domain will be the order of [the number of
   egde routers]^2, while it will become the order of the number of edge
   routers when the flow is defined by {*, egress edge router} with LSP
   merge assumed.  Topology-driven LSP establishment is suitable for
   the backbone domain which handles large number of end-end flows since
   it can provide aggregated paths regardless of the number of end-end
   flows, and is suitable for the network with relatively large number
   of transit routers rather than edge routers.  Note that the LSP
   merging capability is desirable for scalability in terms of the
   number of edge routers.  In order to make topology-driven LSP
   provisioning applicable to the networks which include a number of
   domains, hierarchical LSP configuration is strongly desirable
   [RFC2105].  If not, issues of L3 processing bottleneck will arise at
   domain boundary routers.

   Topology-driven aggregated LSPs should not be extended beyond the
   points where the processing for individual end-end flows (e.g.,
   security checking or QoS control) should be carried out.  They
   should be terminated at those points, e.g., domain border routers
   between ISPs and customer networks.

   With regard to bandwidth, best-effort aggregated LSPs with no
   committed bandwidth will be provided as a default.  But it would be
   possible to provide certain bandwidth for topology-driven aggregated
   LSPs, although it would be a kind of static bandwidth allocation like
   least line services instead of on-demand resource allocation for
   individual end-end flows.  The amount of necessary bandwidth for
   the aggregated LSPs should be properly estimated taking the tradeoff



Katsube, et al.            Expires Dec. 1997                    [Page  3]

Internet Draft        Interoperation Between LSPs              June 1997


   between cost for bandwidth and provision of enough bandwidth to avoid
   LSP congestion into account.  Note that point-point LSP mesh
   configuration with no LSP merge would be adequate for ease of traffic
   control, although it has a scaling problem with regard to the number
   of LSPs.

   Even if some amount of configured bandwidth is allocated to the
   aggregated LSP, packet level priority control or scheduling should be
   carried out at the ingress point of the LSP in order to differentiate
   end-end quality of services among flows which share the same LSP, or
   in order to avoid congestion of the LSP because of the mis-behavior
   of a certain flow.  That requires ingress routers higher performance
   and sophisticated packet processing functionality.


2.2  Data-driven LSP

   Data-driven LSPs are initiated by the detection of a specific data
   packet (e.g., specific upper layers) or by the result of measurement
   of the data traffic[RFC2098].  Currently available control protocols
   for data-driven LSPs are suitable for accommodating fine granularity
   flows defined by, e.g., {L3_src.host, L3_dst.host} or {L3_src.host,
   L3_dst.host, dst.protocol/port}.

   Only the specific packet flow (based on their L3 or upper layer
   information) are delivered from an ingress edge router (or hosts) to
   an egress edge routers (or hosts) without conventional L3 header
   processing.  You should wait for the LSPs to be established each
   time individual packet flow are generated, which may cause delay for
   establishing LSPs, and may cause largeer LSP control overhead due to
   frequent establishment or release.

   The number of required LSPs at a domain does not depend on the number
   of edge routers or hosts, but on the number of active end-to-end
   flows.  Data-driven, fine granularity LSP establishment, therefore,
   is suitable for the domain in which there are relatively large number
   of edge routers but traffic is not evenly dispersed among them.
   It would not be adequate for large scale networks which accommodate
   large number of end-end flows.

   Establishing LSPs accommodating aggregated flow as shown in section
   2.1 by the trigger of data packet arrival may be useful for reducing
   the number of LSPs, though the issue of LSP setup latency may still
   remain.

   Data-driven LSPs would be useful at the point where the processing
   for individual end-end flows (e.g., security checking or QoS
   control) should be carried out, e.g., border routers between the ISP
   and the customer network. The routers with data-driven LSP control



Katsube, et al.            Expires Dec. 1997                    [Page  4]

Internet Draft        Interoperation Between LSPs              June 1997


   capability can check initial packet of individual end-end flow
   through conventional packet processing, then they can establish the
   LSPs if they lend themselves to such.

   With regard to bandwidth, best-effort LSPs with no committed
   bandwidth will be provided as a default for individual end-end
   flows.  But it would be possible to provide certain bandwidth for
   data-driven end-end LSPs without using L3 resource reservation
   mechanism (e.g., RSVP) although it would be a kind of static
   bandwidth allocation like dial-up circuit services.
   However it cannot provide individual end-end flow with optimal
   bandwidth or QoS, it enables to avoid serious degradation of end-end
   quality even in the congested state without wide deployment of L3
   resource reservation protocol.

   The amount of necessary bandwidth for those LSPs becomes the sum of
   bandwidth for individual LSPs.  That enables to reduce necessary
   bandwidth compared with providing static bandwidth for topology-
   driven aggregated LSPs regardless of actual traffic pattern,
   and avoids any effect of the mis-behavior of a certain flow to any
   other flows sharing the same ingress/egress edge routers without
   using sophisticated L3 processing capability.


2.3  Reservation-driven LSP

   Reservation-driven LSPs are initiated by the reception of L3 resource
   reservation requests for a specific end-end flow.  The granularity
   levels of the reservation-driven LSPs depends on the flow granularity
   indicated by the resource reservation messages.  In the case of RSVP
   version 1, for instance, fine granularity such as {L3_src.host,
   L3_dst.host, dst.protocol/port} is used as a default.

   In large scale networks which accommodate a large number of hosts,
   namely a large number of end-end flows with bandwidth request, each
   router will have to maintain extremely huge amount of states of
   reservation flows, which may cause some limitation in the size of the
   networks.  This scalability issue may be resolved if the resource
   reservation protocol is revised to be able to handle aggregation; a
   reservation for a group of flows.



3. Interoperation of Distinct Type of LSPs

   According to analyses described above, it can be said that the
   topology-driven LSP which conveys aggregated flow, the data-driven
   LSP which is dedicated to a specific end-end flow, and reservation-
   driven LSP which is also dedicated to a specific end-end flow have



Katsube, et al.            Expires Dec. 1997                    [Page  5]

Internet Draft        Interoperation Between LSPs              June 1997


   their own applicable areas.

   Several possible relationships between topology-driven aggregated
   LSPs and data-driven more specific LSPs (with/without certain
   bandwidth) are described in this section.

   It is assumed, in figure 1, that AS-a and AS-c are capable of
   establishing Data-driven LSPs for selected end-end flows (specified
   by {L3_src.host, L3_dst.host}), while AS-b provides topology-driven
   LSP mesh for aggregated flows.  AS-b actually can be multiple ASs,
   which constitute hierarchically configured LSPs.
   Note that the topology-driven LSPs can be extended to include AS
   border router BR-a4 and BR-c4 provided that they can handle topology-
   driven LSP control protocols.  In that case, the topology-driven LSP
   is originated at BR-a4 and is terminated at BR-c4.
   The ER denotes Edge Router which accommodates non-LSP capable devices
   and terminates LSPs.  It can be hosts which is capable of handling
   LSPs also.  The IR and BR denote Internal Router and AS Border Router
   respectively.

   Three scenarios regarding the operational relationship between these
   ASs are shown below.


[Case 1] L3 Interworking with Optional Merging at Aggregation Point

   Border routers of the topology-driven AS-b (BR-b1 and BR-b3) are
   assumed to have capabilities to originate or terminate data-driven
   LSPs in this case.  That means that BR-b1 and BR-b3 should participate
   in the data-driven LSP control protocol operated in AS-a and AS-c
   respectively.
   (As already noted, the termination points of topology-driven LSP can
    be shifted to the border routers of AS-a (BR-a4) and AS-c (BR-c4)
    respectively)

   As shown in figure 1, the egress router BR-a4 at AS-a and the ingress
   router BR-c4 at AS-c can switch packets instead of L3 processing if
   they like.  In addition, BR-b1 at the ingress point of the
   topology-driven AS-b is able to switch packets received from
   data-driven LSPs (ER-a1 -> IR-a3 -> BR-a4 -> BR-b1, and ER-a2 ->
   IR-a3 -> BR-a4 -> BR-b1) without L3 processing into the
   topology-driven LSP (BR-b1 -> IR-b2 -> BR-b3), which is regarded as
   "merging" of LSPs.  This is because the granularity of the data-
   driven  LSPs is finer than the granularity of the topology-driven
   LSP.  Note that the BR-b1 should be able to handle multipoint-to-
   point merging of LSPs.  (e.g., ATM switch should avoid cell level
   interleaving among distinct packets).

   Above-mentioned switched forwarding capability does not apply to the



Katsube, et al.            Expires Dec. 1997                    [Page  6]

Internet Draft        Interoperation Between LSPs              June 1997


   BR-b3 which is the termination point of the topology-driven aggregated
   LSP and the origination point of the data-driven LSP with finer flow
   granularity, but L3 processing is needed.


[Case 2] Data-driven LSP over Topology-driven LSP Tunnel

   Border routers of the topology-driven AS-b (BR-b1 and BR-b3) are
   assumed to have capabilities to originate, terminate, and relay
   data-driven LSPs in this case.  In addition, BR-b1 is assumed to
   memorizes that it has a topology-driven aggregated LSP dedicated to
   the flow specified by {BR-b1, BR-b3} toward BR-b3.
   (As already noted, the termination points of topology-driven LSP can
    be shifted to the border routers of AS-a (BR-a4) and AS-c (BR-c4)
    respectively)

   When BR-b1 wants to set up a data-driven LSP dedicated to a flow
   specified by {H1, H3} or {H2, H4}, it exchanges a data-driven LSP
   control message with BR-b3 which is a logical neighbor with the
   support of topology-driven LSP from BR-b1 to BR-b3.  Then the
   data-driven LSP is established from ER-a1 (or ER-a2) to ER-c1 (or
   ER-c2) by passing through the topology-driven aggregated LSP as a
   tunnel.

   This can be regarded as a hierarchical LSP configuration with two
   levels of label; one applied by ER-a1 or ER-a2 for the {H1, H3} or
   the {H2, H4} flow and the other applied by BR-b1 for the topology-
   driven tunnel toward BR-b3. This enables configuration of end-to-end
   data-driven LSPs without having internal routers in topology-driven
   network be aware of dara-driven LSP control protocol.


[Case 3] Data-driven LSP independent of Topology-driven LSP Tunnel

   Bandwidth allocation for LSPs dedicated to end-end flow may be
   supported over topology-driven aggregated LSPs, or may be supported
   independent of topology-driven LSPs.

   The former case is regarded as an extension of Case 2, and requires
   topology-driven LSPs to be given a proper amount of bandwidth.
   Bandwidth of the topology-driven LSP should be managed to avoid
   overload of itself.  Dynamic changes of allocated bandwidth of
   topology-driven LSPs in response to their usage may be useful if it
   is possible.

   In the latter case; Case 3; there is no interoperation between
   the topology-driven LSP and the data-driven LSP.  The topology-driven
   aggregated LSPs do not have to be given certain bandwidth, although
   additional number of LSPs for end-end flow with certain bandwidth



Katsube, et al.            Expires Dec. 1997                    [Page  7]

Internet Draft        Interoperation Between LSPs              June 1997


        Data-driven        Topology-driven        Data-driven
           (AS-a)             (AS-b)                (AS-c)
      <-------------->     <-------------->     <-------------->
  H1--ER                                                      ER--H3
     (a1)    IR     BR     BR     IR     BR     BR     IR    (c1)
            (a3)   (a4)   (b1)   (b2)   (b3)   (c4)   (c3)
  H2--ER                                                      ER--H4
     (a2)                                                    (c2)


  [Case 1] L3 Interworking with Optional Merging at Aggregation Point

       (for {H1,H3})                             (for {H1,H3})
      L3-----::-----::-----                -----::-----::-----L3
                           L3=====::=====L3
      L3-----::-----::-----  (for{b1,b3})  -----::-----::-----L3
       (for {H2,H4})                             (for {H2,H4})

       (for {H1,H3})                             (for {H1,H3})
      L3-----::-----::-----\               -----::-----::-----L3
                           ::=====::=====L3
      L3-----::-----::-----/ (for{b1,b3})  -----::-----::-----L3
       (for {H2,H4})                             (for {H2,H4})


  [Case 2] Data-driven LSP over Topology-driven LSP Tunnel

       (for {H1,H3})                             (for {H1,H3})
      L3-----::-----::-----::   tunnel   ::-----::-----::-----L3
                             =====::=====
      L3-----::-----::-----::(for{b1,b3})::-----::-----::-----L3
       (for {H2,H4})                             (for {H2,H4})


  [Case 3] Data-driven LSP independent of Topology-driven LSP

       (for {H1,H3})                             (for {H1,H3})
      L3-----::-----::-----::-----::-----::-----::-----::-----L3
                             =====::=====
      L3-----::-----::-----::-----::-----::-----::-----::-----L3
       (for {H2,H4})                             (for {H2,H4})



      # "::" denotes switched forwarding.
      #  ------::------ Data-driven LSP
      #  ======::====== Topology-driven LSP

                           Figure 1



Katsube, et al.            Expires Dec. 1997                    [Page  8]

Internet Draft        Interoperation Between LSPs              June 1997


   should be controlled in AS-b independent of the existense of the
   topology-driven aggregated LSPs.
   (Reservation-driven LSPs will also be controlled independent of the
    existense of the topology-driven best-effort LSPs)

   In this case, all the LSRs in AS-b should be able to handle both
   topology-driven and data-driven LSPs.


5.  Security Considerations

   Security considerations are not addressed in this memo.


6.  Acknowledgement

   I would like to thank Yakov Rekhter and Paul Doolan for their help
   and suggestions in writing this document.


7.  References

[ARIS] R.Woundy, A.Wiswanathan, N.Feldman, R.Biovie, "ARIS:
        Aggregated Route-Based IP Switching",
        draft-woundy-aris-ipswitching-00.txt, November, 1996.
[RFC2098] Y.Katsube, K.Nagami, H.Esaki, "Toshiba's Router
        Extensions for ATM", IETF RFC2098, February, 1997.
[RFC2105] Y.Rekhter, B.Davie, D.Katz, E.Rosen, G.Swallow,
        "Cisco System's Tag Switching Overview", IETF RFC2105,
        February, 1997.


8.  Authors' Addresses

     Yasuhiro Katsube
        R&D Center, Toshiba Corporation,
        1 Komukai-Toshiba-cho, Saiwai-ku,
        Kawasaki, 210, Japan
        Email: katsube@isl.rdc.toshiba.co.jp

     Hiroshi Esaki
        Computer and Network Division,
        Toshiba Corporation,
        1-1-1 Shibaura,
        Minato-ku, 105-01, Japan.
        Email: hiroshi@isl.rdc.toshiba.co.jp






Katsube, et al.            Expires Dec. 1997                    [Page  9]