Network Working Group                                  Wataru Imajuku
Internet Draft                                                    NTT
draft-imajuku-ml-routing-02.txt                              Eiji Oki
Expiration Date: December 2002                                    NTT
                                                       Kohei Shiomoto
                                                                  NTT
                                                       Satoru Okamoto
                                                                  NTT
                                                            June 2002


     Multilayer routing using multilayer switch capable LSRs
                draft-imajuku-ml-routing-02.txt


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.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.



Abstract


   The integration of multilayer switching capabilities within one
   box, such as the packet-switch capability (PSC) and the lambda-
   switch capability (LSC) under the MPLS/Generalized-MPLS control
   mechanism, paves the way for achieving network resource optimization
   considering multilayer routing. This document clarifies the model of
   the GMPLS-controlled integrated PSC/LSC label switch router (LSR)
   and discusses the requirements of the routing extensions needed to
   achieve optimized multilayer traffic engineering.




Imajuku                                                        [Page 1]


Internet Draft       draft-imajuku-ml-routing-02.txt       28 June 2002


1. Summary for Sub-IP Area

1.1. Summary

   This document adds extensions to the routing protocols
   with GMPLS extensions in order to support multilayer routing.

1.2. Where does it fit in the picture of the Sub-IP Work

   This work fits in the CCAMP.

1.3. Why is it targeted at this WG

   This draft is targeted at the CCAMP WG, because this draft specifies
   the extensions to routing protocols to support multilayer routing
   of hierarchical label switched paths in the GMPLS network.
   This type of multilayer routing in the GMPLS network is within the
   scope of the CCAMP WG.

1.4. Justification

   The WG should consider this document as it specifies the extensions
   to routing protocols in support of multilayer routing of hierarchical
   label switched paths in the GMPLS network.



2. Introduction


   Generalized-MPLS (GMPLS) facilitates the realization of seamless
   integration of IP Networks with legacy SDH/SONET or Photonic
   networks. In particular, integration of the packet switching
   capability and the photonic switching technology under a unified
   GMPLS control plane would significantly enhance the forwarding
   capacity of the IP network, while greatly reducing number
   of network elements to be managed in an IP network [Sato02].
   One of the other forces driving the construction of a unified
   GMPLS control plane is the desire to implement a multilayer routing
   capability, which would enable effective network resource
   utilization of both the IP-layer and the SDH/SONET or Photonic-layer
   in the next generation high capacity IP+Photonic network [Oki02].


   In such a network, each LSR would contain multiple-type switching
   capabilities such as PSC and Time-Division-Multiplexing



Imajuku                                                        [Page 2]


Internet Draft       draft-imajuku-ml-routing-02.txt       28 June 2002


   (or SDH/SONET XC) (TDM), PSC and Lambda switching (LSC), and LSC and
   Fiber switching (FSC) under the unified GMPLS control plane.
   These LSRs with integrated switch capabilities are required to hold
   and advertise resource information of not only link states and network
   topology, but also those of the portion of internal LSR resources to
   terminate hierarchical label switched paths (LSPs), since circuit switch
   capable units such as TDMs, LSCs, and FSCs require rigid resources.
   For example, an LSR with the PSC+LSC integrated switching capability
   can forward an optical label switched path (O-LSP) but can never
   terminate the O-LSP, if there is no unused adaptation capability
   between the PSC and the LSC.


   Therefore, the concept of advertising adaptation capability to
   terminate LSPs, within such multilayer LSRs is essential to
   establishing multilayer route calculation of LSPs.
   This concept enables a local LSR to discriminate remote LSRs based on
   whether or not they have the adaptation capability to terminate O-LSPs
   at PSCs within the remote LSRs. This realizes multilayer routing such
   that the electrical label switched path (E-LSP) set-up automatically
   triggers new O-LSP set-up and successfully forwards IP traffic
   even if there is no existing O-LSP.


   This draft proposes the idea of discriminating the forwarding
   capability and adaptation capability of each switching capability
   in the LSR. Then, this draft proposes to redefine the interface
   switching capability descriptor discussed in [GMPLS-ROUT] and
   [GMPLS-OSPF] as the information describing the forwarding capability
   of each switching capability in LSRs, and to add an interface
   adaptation capability descriptor disseminating the LSP termination
   capability within multilayer LSRs. The content of this document is
   as follows. First, the need for redefinition and addition of these
   descriptors is discussed. Second, a format is proposed for the
   interface adaptation capability descriptor. Third, usage examples are
   provided of a redefined interface switching capability descriptor
   and interface adaptation capability descriptor for several kinds of
   multilayer LSRs.



3. Interface adaptation capability descriptor


   This draft proposes that the interface switching capability descriptor
   be re-interpreted as the forwarding capability information from



Imajuku                                                        [Page 3]


Internet Draft       draft-imajuku-ml-routing-02.txt       28 June 2002


   an in-bound interface to an out-bound interface of a switch capability.
   Also, this draft proposes an interface adaptation capability
   descriptor that can be interpreted as the adaptation capability
   information from an in-bound interface to the adaptation capability or
   from the adaptation capability to an out-bound interface of the switch
   capability. By introducing such a re-definition and new descriptor,
   the routing engine can swiftly search which LSRs can terminate a certain
   encoding type of LSP and successfully establish an LSP tunnel between
   two PSCs.


   As an example, this section considers an E-LSP+O-LSP multiple
   networking layer domain comprising PSC LSRs, LSC LSRs, and PSC+LSC LSRs.
   In the networking domain, an E-LSP networking layer has an E-LSP
   switching capability such as PSC-LSRs or PSC+LSC LSRs, and the links
   combining these LSRs are O-LSPs. On the other hand, the O-LSP networking
   layer has an O-LSP switching capability such as LSC-LSRs or PSC+LSC-LSRs,
   and the links combining these LSRs are fiber links. Therefore, the LSRs
   within this multiple networking layer domain shall have both these link
   states, i.e., not only fiber links but also O-LSPs, to select correctly
   routes of E-LSPs.


   The LSRs discriminates the type of these links by the interface
   switching capability descriptor in LSAs [LSP-HIER]. The interface
   switching capability at both ends of a TE-link shall be [LSC, LSC],
   [PSC, LSC], or [TDM, LSC] for fiber links carrying a "lambda" label.
   On the other hand, the interface switching capability at both ends of
   a TE-link shall be [PSC, PSC] for O-LSPs that carry a "shim" header
   label, or shall be [TDM, TDM] or [PSC, TDM] for O-LSPs carrying "TDM
   time slot" labels. Based on the interface switching capability descriptor,
   the LSRs can impose proper constraints in order to calculate the route of
   LSPs. For example, LSRs can understand that a remote TDM LSR with
   [TDM, LSC] link cannot forward O-LSPs, but can terminate O-LSPs and
   switch the "TDM time slot".


   However, LSRs cannot properly understand the O-LSP termination
   capability of remote LSRs, especially if the LSRs have a hybrid switch
   architecture such as a PSC+TDM+LSC LSR as shown below. In the LSR,
   LSC may have a direct inner interface not only to TDM but also to PSC.
   The O-LSP can be terminated by both DXC and PSC. This kind of hybrid
   architecture shall be very common in Photonic networks.






Imajuku                                                        [Page 4]


Internet Draft       draft-imajuku-ml-routing-02.txt       28 June 2002


                        _______
                 ______|       |______
                |    __|  PSC  |__    |
                |   |  |_______| /|\  |
                |  \|/  _______   |   |
                |   |__|       |__|  /|\
               \|/   __|  DXC  |__    |
                |   |  |_______| /|\  |
                |  \|/   _______  |   |
                |   |__|       |__|   |
                |______|       |______|
                       |       |
          __\     /|___|       |___|\
            /    | |___|       |___| |   Fiber #1
         ========| |___|  LSC  |___| |========
                 | |___|       |___| |
                  \|   |       |   |/
                       |       |
                       .       .
                       .       .
          __\     /|___|       |___|\
            /    | |___|       |___| |   Fiber #N
         ========| |___|       |___| |========
                 | |___|       |___| |
                  \|   |       |   |/
                       |_______|


   The problem with the use of the interface switching capability
   descriptor at the PSC+TDM+LSC LSR is the shortage of LSP termination
   capability information. The PSC+TDM+LSC LSRs provides only switching
   capability information, in other words, the forwarding capability
   information for each switching capability. Therefore, remote LSRs
   cannot properly understand which switching capability O-LSPs can be
   terminated at the PSC+TDM+LSC LSR. In the LSR, an O-LSP can be
   terminated both by the PSC and TDM, but the interface switch
   capability descriptor cannot provide sufficient information for O-LSP
   termination capability in the PSC+TDM+LSC LSR.


   Similar circumstances can occur, if a switching fabric that supports
   both PSC and L2SC functionalities is assembled with LSC with "lambda"
   (photonic) encoding. In the switching fabric, some interfaces terminate
   O-LSPs and perform L2 switching, other interfaces terminate O-LSPs and
   perform L3 switching.




Imajuku                                                        [Page 5]


Internet Draft       draft-imajuku-ml-routing-02.txt       28 June 2002



   Thus, the interface switching capability descriptor provides the
   information mainly for the forwarding capability. In order for remote
   LSRs to understand properly the termination capability of LSRs, the
   addition of new information to the interface switching capability
   descriptor is essential in achieving seamless multilayer routing in
   a multiple layer networking domain. This approach can achieve seamless
   routing such as an E-LSP set-up signaling automatically triggering new
   O-LSPs between the LSRs that do not have a preferred O-LSP to carry the
   E-LSP with the knowledge of both the fiber and O-LSP link state, even
   if multiple kinds of switching capabilities are assembled with LSCs
   by miscellaneous switching architectures.



4. Encoding of interface adaptation capability descriptor


   The interface adaptation capability descriptor is sub-TLV (of type TBD)
   of Link TLV (with type TBD) [OSPF-TE]-[ISIS-TE]. The length is the
   length of the value field in octets. The reason for defining new sub-TLV
   for the interface adaptation capability descriptor is to achieve simple
   and swift look-up of LSA-DB. The routing engine can ignore this sub-TLV
   at a cut-through LSR, and only look-up this sub-TLV at LSRs at which
   LSPs are terminated.


      Sub-TLV Type      Length    Name
                15    variable    Interface Switching Capability Descriptor
                TBD   variable    Interface Adaptation Capability Descriptor


   The format of the value field is as shown 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Switching Cap |Num. ADP Types |           Reserved            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Enc. Type 1  |Client S.Type 1|             G-PID 1           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Bandwidth Encoding 1                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Number of Adaptations 1                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Imajuku                                                        [Page 6]


Internet Draft       draft-imajuku-ml-routing-02.txt       28 June 2002


      |           Number of Unreserved Adaptations 1 at priority 1    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Number of Unreserved Adaptations 1 at priority 2    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Number of Unreserved Adaptations 1 at priority 3    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Number of Unreserved Adaptations 1 at priority 4    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Number of Unreserved Adaptations 1 at priority 5    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Number of Unreserved Adaptations 1 at priority 6    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Number of Unreserved Adaptations 1 at priority 7    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Enc. Type 2  |Client S.Type 2|             G-PID 2           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Bandwidth Encoding 2                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Number of Adaptations 2                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Number of Unreserved Adaptations 2 at priority 1    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Number of Unreserved Adaptations 1 at priority 2    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                         ...
                                         ...
      |           Number of Unreserved Adaptations n at priority 5    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Number of Unreserved Adaptations n at priority 6    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Number of Unreserved Adaptations n at priority 7    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The Switching Capability (Switching Cap): 8 bits

      This field contains one of the following values:

           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)



Imajuku                                                        [Page 7]


Internet Draft       draft-imajuku-ml-routing-02.txt       28 June 2002




   Number of adaptation types (Number of IF Types): 8 bits

      This field contains a number between 0-255, which describes number
      of adaptation capability types connected to the client switching
      capability on the master switching capability described in the
      Switching Cap field.


   Encoding type  (Enc. Type): 8 bits
      This field indicates the type of LSP that can be terminated by
      the adaptation capability. The values are defined in [GMPLS-SIG].


   Client switching capable type (Client S. Type): 8 bits
      This field describes the client switching capability. This field
      contains one of the values described in the explanation of the
      Switching Cap field above.


   Generalized-PID (G-PID): 16 bits
      An identifier of the payload carried by an LSP that can be
      terminated by the adaptation capability. The values are defined
      in [GMPLS-SIG].


   Bandwidth Encoding: 32 bits
      Bandwidth encoding describes the bandwidth of an LSP that can be
      terminated by the adaptation capability.
      The values are defined in [GMPLS-SIG].


   Number of Adaptations: 32 bits
      The value of this field describes number of adaptation capabilities
      with the above described attribute.


   Number of Unreserved Adaptations: 32 bits
      The value of this field describes number of unreserved adaptation
      capabilities with the above described attribute.



5. Example of interface adaptation capability descriptor




Imajuku                                                        [Page 8]


Internet Draft       draft-imajuku-ml-routing-02.txt       28 June 2002



5.1 PSC+LSC LSR


                        _______
              _________|       |_________
             |   ______|  PSC  |______   |
             |  |    __|       |__    | /|\
            \|/ |   |  |_______|  |  /|\ |
             | \|/  |            /|\  |  |
             |  |  \|/  _______   |   |  |
             |  |   |__|       |__|   |  |
             |  |______|       |______|  |
             |_________|       |_________|
                       |       |
          __\     /|___|  PXC  |___|\
            /    | |___|       |___| |   Fiber #1
         ========| |___|       |___| |========
                 | |___|       |___| |
                  \|   |       |   |/
                       |_______|


   The first example is PSC+LSC-LSR. The PSC has both STM-16 POS and
   STM-64 POS interfaces. The LSC itself is a transparent PXC so that
   the LSC can forward not only an SDH encoded O-LSP but also an Ethernet
   encoded O-LSP. In this case, the fiber interface of the LSR advertises
   the interface switching capability descriptor as follows:

          Interface Switching Capability Descriptor 1:
             Interface Switching Capability = PSC-1
             Encoding = SDH
             Max LSP Bandwidth[p] = 2.5 Gbps, for all p

          Interface Switching Capability Descriptor 2:
             Interface Switching Capability = PSC-1
             Encoding = SDH
             Max LSP Bandwidth[p] = 10.0 Gbps, for all p

          and

          Interface Switching Capability Descriptor 3:
             Interface Switching Capability = LSC
             Encoding = Lambda (photonic)
             Reservable Bandwidth = Determined by optical technology limits




Imajuku                                                        [Page 9]


Internet Draft       draft-imajuku-ml-routing-02.txt       28 June 2002


   The LSR also advertises the interface adaptation capability descriptor
   as follows:

          Interface Adaptation Capability Descriptor:
             Switching Capability = LSC
             Number of IF Types = 2
             Encoding 1 = SDH
             Client S. Type 1 = PSC-1
             G-PID 1 = POS - Scrambling, 16 bit CRC
             Bandwidth Encoding 1[p] = 2.5 Gbps, for all p
             Number of Adaptations 1 = 1
             Number of Unreserved Adaptations 1 = variable
             Encoding 2 = SDH
             Client S. Type 2 = PSC-1
             G-PID 2 = POS - Scrambling, 16 bit CRC
             Bandwidth Encoding 2[p] = 10.0 Gbps, for all p
             Number of Adaptations 2 = 2
             Number of Unreserved Adaptations 2 = variable



5.2 PSC/L2SC+LSC LSR


                        _______
              _________|       |_________
             |   ______| PSC/  |______   |
             |  |    __|  L2SC |__    | /|\
            \|/ |   |  |_______|  |  /|\ |
             | \|/  |            /|\  |  |
             |  |  \|/  _______   |   |  |
             |  |   |__|       |__|   |  |
             |  |______|       |______|  |
             |_________|       |_________|
                       |       |
          __\     /|___|  PXC  |___|\
            /    | |___|       |___| |   Fiber #1
         ========| |___|       |___| |========
                 | |___|       |___| |
                  \|   |       |   |/
                       |_______|


   The second example is PSC/L2SC+LSC-LSR. The PSC/L2SC have STM-16 POS
   interfaces. The LSC itself is a transparent PXC
   so that the LSC can forward not only an SDH encoded O-LSP but



Imajuku                                                        [Page 10]


Internet Draft       draft-imajuku-ml-routing-02.txt       28 June 2002


   also an Ethernet encoded O-LSP. In this case, the fiber interface of
   the LSR advertises the interface switching capability descriptor
   as follows:

          Interface Switching Capability Descriptor 1:
             Interface Switching Capability = PSC-1
             Encoding = SDH
             Max LSP Bandwidth[p] = 2.5 Gbps, for all p

          Interface Switching Capability Descriptor 2:
             Interface Switching Capability = L2SC
             Encoding = SDH
             Max LSP Bandwidth[p] = 2.5 Gbps, for all p

          and

          Interface Switching Capability Descriptor 3:
             Interface Switching Capability = LSC
             Encoding = Lambda (photonic)
             Reservable Bandwidth = Determined by optical technology limits

   The LSR also advertises the interface adaptation capability descriptor
   as follows:

          Interface Adaptation Capability Descriptor:
             Switching Capability = LSC
             Number of IF Types = 2
             Encoding 1 = SDH
             Client S. Type 1 = PSC-1
             G-PID 1 = POS - Scrambling, 16 bit CRC
             Bandwidth Encoding 1 [p] = 2.5 Gbps, for all p
             Number of Adaptations 1 = 3
             Number of Unreserved Adaptations 1 = variable
             Encoding 2 = SDH
             Client S. Type 2 = L2SC
             G-PID 2 = POS - Scrambling, 16 bit CRC
             Bandwidth Encoding 2 [p] = 2.5 Gbps, for all p
             Number of Adaptations 2 = Shared with above one
             Number of Unreserved Adaptations 2 = none



5.3 DXC+LSC LSR






Imajuku                                                        [Page 11]


Internet Draft       draft-imajuku-ml-routing-02.txt       28 June 2002


                        _______
              _________|       |_________
             |   ______|  DXC  |______   |
             |  |    __|       |__    | /|\
            \|/ |   |  |_______|  |  /|\ |
             | \|/  |            /|\  |  |
             |  |  \|/  _______   |   |  |
             |  |   |__|       |__|   |  |
             |  |______|       |______|  |
             |_________|       |_________|
                       |       |
          __\     /|___|  PXC  |___|\
            /    | |___|       |___| |   Fiber #1
         ========| |___|       |___| |========
                 | |___|       |___| |
                  \|   |       |   |/
                 DWDM  |_______|


   The second example is PSC+LSC-LSR. The STM-16 interface of this Digital
   Cross Connect (DXC) supports two types of SDH multiplexing hierarchy.
   The LSC itself is a transparent PXC with external DWDM so that the
   LSC can forward not only STM-16 encoded O-LSP but also an STM-64
   encoded O-LSP and so on. In this case, the fiber interface of the LSR
   advertises the interface switching capability descriptor as follows:

          Interface Switching Capability Descriptor:
             Interface Switching Capability = TDM
             Encoding = SDH
             Min LSP Bandwidth[p] = VC-3
             Max LSP Bandwidth[p] = STM-16, for all p

          Interface Switching Capability Descriptor:
             Interface Switching Capability = TDM
             Encoding = SDH
             Min LSP Bandwidth[p] = VC-4
             Max LSP Bandwidth[p] = STM-16, for all p

          and

          Interface Switching Capability Descriptor:
             Interface Switching Capability = LSC
             Encoding = SDH
             Reservable Bandwidth = Determined by DWDM

   The fiber interface of the LSR also advertises the interface



Imajuku                                                        [Page 12]


Internet Draft       draft-imajuku-ml-routing-02.txt       28 June 2002


   adaptation capability descriptor as follows:

          Interface Adaptation Capability Descriptor:
             Switching Capability = LSC
             Number of IF Types = 1
             Encoding = SDH
             Client S. Type = TDM
             G-PID = Byte Synchronous mapping of E1
             Bandwidth Encoding [p] = 2.5 Gbps, for all p
             Number of Adaptations = 3
             Number of Unreserved Adaptations = variable



5.4 PSC+DXC+LSC LSR


                        _______
                 ______|       |______
                |    __|  PSC  |__    |
                |   |  |_______| /|\  |
                |  \|/  _______   |   |
                |   |__|       |__|  /|\
               \|/   __|  DXC  |__    |
                |   |  |_______| /|\  |
                |  \|/  _______   |   |
                |   |__|       |__|   |
                |______|       |______|
                       |       |
             __\     /||       ||\
               /    | ||       || |   Fiber #1
            ========| ||  OXC  || |========
                    | ||       || |
                     \||       ||/
                   DWDM|_______|
               (SDH framed)


   The third example is PSC+DXC+LSC-LSR. The O-LSP can be terminated
   by both DXC and PSC. This example assumes that DWDM and OXC are
   connected in such a way that each interface on the OXC handles
   multiple wavelengths individually. In this case, an interface at
   the OXC is considered to be LSC, and not FSC. A TE link is a group
   of one or more of the interfaces at the OXC. All lambdas associated
   with a particular interface are required to have identifiers unique
   to that interface, and these identifiers are used as labels



Imajuku                                                        [Page 13]


Internet Draft       draft-imajuku-ml-routing-02.txt       28 June 2002


   (see 3.2.1.1 of [GMPLS-SIG]).


   The adaptation capability of LSC is directly faced with both DXC and
   PSC. These interfaces are STM-16 interfaces. The STM-16 interface of
   the DXC supports two types of SDH multiplexing hierarchy. The DXC also
   has the interface faced with PSC and whose interface type is the STM-16
   POS interface. In this case, the fiber interface of the LSR advertises
   the interface switching capability descriptor as follows:

          Interface Switching Capability Descriptor:
             Interface Switching Capability = PSC-1
             Encoding = SDH
             Max LSP Bandwidth[p] = 2.4 Gbps, for all p

          Interface Switching Capability Descriptor:
             Interface Switching Capability = TDM
             Encoding = SDH
             Min LSP Bandwidth[p] = VC-3
             Max LSP Bandwidth[p] = STM-16, for all p


          Interface Switching Capability Descriptor:
             Interface Switching Capability = TDM
             Encoding = SDH
             Min LSP Bandwidth[p] = VC-4
             Max LSP Bandwidth[p] = STM-16, for all p

          and

          Interface Switching Capability Descriptor:
             Interface Switching Capability = LSC
             Encoding = SDH
             Reservable Bandwidth = STM-16

   The fiber interface of the LSR also advertises the interface adaptation
   capability descriptor as follows:

          Interface Adaptation Capability Descriptor 1:
             Switching Capability = LSC
             Number of IF Types = 2
             Encoding 1 = SDH
             Client S. Type 1 = PSC-1
             G-PID 1 = POS - Scrambling, 16 bit CRC
             Bandwidth Encoding 1 [p] = 2.5 Gbps, for all p
             Number of Adaptations 1 = 1



Imajuku                                                        [Page 14]


Internet Draft       draft-imajuku-ml-routing-02.txt       28 June 2002


             Number of Unreserved Adaptations 1 = variable
             Encoding 2 = SDH
             Client S. Type 2 = TDM
             G-PID 2 = Byte Synchronous mapping of E1
             Bandwidth Encoding 2 [p] = 2.5 Gbps, for all p
             Number of Adaptations 2 = 1
             Number of Unreserved Adaptations 2 = variable

          and

          Interface Adaptation Capability Descriptor 2:
             Switching Capability = TDM
             Number of IF Types = 1
             Encoding = SDH
             Client S. Type = PSC-1
             G-PID = POS - Scrambling, 16 bit CRC
             Bandwidth Encoding [p] = 2.5 Gbps, for all p
             Number of Adaptations = 1
             Number of Unreserved Adaptations = variable


   As discussed in these examples, the dissemination of the interface
   adaptation capability descriptor helps to search correctly LSRs
   to terminate LSPs routed by circuit switch capabilities such as FSC,
   LSC, and TDM.



6. Security Considerations


   Security issues are not discussed in this draft.



7. References


   [Sato02] K.-I. Sato, N. Yamanaka, Y. Takigawa, M. Koga, S. Okamoto,
   K. Shiomoto, E. Oki, and W. Imajuku, "GMPLS-Based Photonic Multilayer
   Router (Hikari Router) Architecture: An Overview of Traffic Engineering
   and Signaling Technology," IEEE Comm. Mag., vol. 40, pp. 96-101, March
   2002.


   [Oki02] E. Oki, K. Shiomoto, S. Okamoto, W. Imajuku, and N. Yamanaka,



Imajuku                                                        [Page 15]


Internet Draft       draft-imajuku-ml-routing-02.txt       28 June 2002


   A heuristic-based multilayer optimum topology design scheme based on
   traffic measurement for IP+Photonic networks," In Proc. of OFC 2002,
   3/2002.


   [GMPLS-ROUT] "Routing extensions in support of generalized MPLS,
   " draft-many-ccamp-gmpls-routing-04.txt (work in progress), 04/02.


   [GMPLS-OSPF] "OSPF extensions in support of generalized MPLS,
   " draft-ietf-ccamp-ospf-gmpls-extensions-07.txt (work in progress),
   05/02.


   [LSP-HIER] "LSP hierarchy with MPLS TE," draft-ietf-mpls-
   lsp-hierarchy-06.txt (work in progress), 05/02.


   [OSPF-TE] "Traffic engineering extensions to OSPF," draft-katz-yeung
   -ospf-traffic-06.txt, 10/01.


   [ISIS-TE] "IS-IS extensions for Traffic Engineering," draft-ietf-isis
   -traffic-04.txt, 08/01.


   [GMPLS-SIG] "Generalized MPLS - signaling functional description,"
   draft-ietf-mpls-generalized-signaling-08.txt (work in progress), 04/02



7. Author information


   Wataru Imajuku
   NTT Network Innovation Laboratories
   1-1 Hikari-no-oka,
   Yokosuka, Kanagawa, 239-0847 Japan
   Phone: +81 468 59 4315
   Fax: +81 468 59 3396
   E-mail: imajyuku@exa.onlab.ntt.co.jp


   Eiji Oki
   NTT Network Innovation Laboratories
   3-9-11 Midori-cho,



Imajuku                                                        [Page 16]


Internet Draft       draft-imajuku-ml-routing-02.txt       28 June 2002


   Musashino-shi, Tokyo 180-8585, Japan
   Phone: +81 422 59 3441
   Fax: +81 422 59 6387
   E-mail: oki.eiji@lab.ntt.co.jp


   Kohei Shiomoto
   NTT Network Innovation Laboratories
   3-9-11 Midori-cho,
   Musashino-shi, Tokyo 180-8585, Japan
   Phone: +81 422 59 4402
   Fax: +81 422 59 6387
   E-mail: shiomoto.kohei@lab.ntt.co.jp


   Satoru Okamoto
   NTT Network Innovation Laboratories
   1-1 Hikari-no-oka,
   Yokosuka, Kanagawa, 239-0847 Japan
   Phone: +81 468 59 4315
   Fax: +81 468 59 3396
   E-mail: okamoto@exa.onlab.ntt.co.jp



























Imajuku                                                        [Page 17]