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


     Multi-layer routing using multi-layer switch capable LSRs
                draft-imajuku-ml-routing-01.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 multi-layer switching capabilities within one 
   box, such as the packet-switch capability (PSC) and the lambda-
   switch capability (LSC) under MPLS/Generalized-MPLS control mechanism,
   paves the way for realizing network resource optimization 
   with consideration of multi-layer 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 realize optimized multi-layer traffic 
   engineering.



Imajuku                                                        [Page 1]





Internet Draft       draft-imajuku-ml-routing-01.txt   28 February 2002

1. Introduction


   Generalized-MPLS (GMPLS) makes it easier to realize the 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 [Shimano01]. One of the other forces 
   driving the construction of a unified GMPLS control plane is the 
   desire to implement multi-layer 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 large
   capacity IP+Photonic network [Oki02].


   In such network, each LSR would contain multiple-type switching 
   capabilities such as PSC and Time-Division-Multiplexing 
   (or SDH/SONET XC) (TDM), PSC and Lambda switching (LSC), LSC and 
   Fiber switching (FSC), etc. These LSRs with integrated switch 
   capabilities are required to hold resource information of not only 
   their own link states and network topology but also those of other 
   LSR's, since circuit switch capable units such as TDMs, LSCs, FSCs 
   require rigid resource reservation unlike PSCs. In addition, these 
   LSRs are also required to discriminate link state data as to which 
   layer these links belong, so as to provide multi-layer routing 
   functionality.

   The implementation of such functionality enables seamless multi-layer
   optimized route calculation such that the conventional label switched 
   path (LSP) call setup automatically triggers new optical label 
   switched path (OLSP) setup where the unused resources of inner 
   interfaces between PSC functional block and LSC functional block 
   in the OLSP destination node are considered.
   If it is not possible to reserve the resources of the inner interface
   between PSC and LSC in the OLSP destination node, a different OLSP is
   setup that connects to a different intermediate LSR, and the LSP-call
   can be accommodated by the new OLSP and subsequent hops through other
   existing OLSPs until it reaches the destination node of the LSP-call.


   This draft proposes several extensions to the link state information 
   of OSPF/ISIS disseminated to all LSRs in the routing area to realize 
   multi-layer routing. The extension of link state information includes
   the basic concept of the interface switching capability descriptor 
   as discussed in [GMPLS-ROURING] and [GMPLS-OSPF]. The content of this
   document is as follows. First, it models the GMPLS-based LSR with 



Imajuku                                                        [Page 2]





Internet Draft       draft-imajuku-ml-routing-01.txt   28 February 2002


   multi-layer switching capabilities. Second, it discusses the aspect of
   multi-layer routing and the specification of the link state 
   advertisements (LSAs). Last, it discusses the interaction with FA-LSP 
   and it's LSAs that are to be disseminated to other LSRs in response 
   to the creation of LSPs. 



2. The node model of GMPLS based LSRs with lambda switching capability


   This section clarifies the model of switching capable in GMPLS-based 
   LSRs to clarify the requirements for multi-layer routing under the 
   unified GMPLS-control plane. 



2.1 LSC-LSR


   The first model is LSR with LSC only. The LSC handles each OLSP to 
   switch from fiber to fiber. This type of LSR does not have packet-
   level switching capability. Therefore, other LSRs in the same routing
   area (or domain) shall recognize that the LSR does not have the 
   functionalities of IP packet routing and LSP switching.


   Requirement: When there is no unused input and output port in the 
   LSR, the LSR shall be identified as an LSC router that has no OLSP
   forwarding capability.


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



Imajuku                                                        [Page 3]





Internet Draft       draft-imajuku-ml-routing-01.txt   28 February 2002


                  \|   |       |   |/
                       |_______|



   If the LSC-LSR does not have wavelength conversion capability 
   (common in most all-optical networks), the information as to which
   wavelength channel can be reserved in a fiber link plays the most
   important role in route selection within OLSP setup. Thus, LSC-
   LSR shall also recognize and advertise the status of the unused 
   wavelength channel number as described in the document [OKI-OLI].


   In the process of constructing the network topology from fiber link 
   state data, each fiber link connected to LSRs may be identified as a 
   TE-link between neighboring LSRs. Component links, which may 
   correspond to wavelength channels or LSC switch ports in one or 
   multiple fibers, are bundled into a TE-link, where all wavelength 
   information is aggregated [LINK-BUNDLE].



2.2 LSR with PSC+LSC


   The second model is LSR with PSC+LSC. The PSC is connected to the 
   LSC via internal interfaces between the PSC function block and 
   the LSC function block. The LSC handles each OLSP to switch 
   from fiber to fiber. This type of LSR offers the switching 
   capabilities of both conventional LSPs and OLSPs. Therefore, other 
   LSRs in the same routing area (or domain) shall recognize that the 
   LSR has the capability of forwarding both IP packets and OLSPs.


   Requirements: 
   If all switch ports of the LSC function block are occupied, an OLSP
   setup call transferring or terminating at the LSR shall be rejected.
   In such a case, other LSRs in the same routing area (or domain) shall 
   recognize that the PSC+LSC router has no LSC reservation capability. 
   If all inner interfaces between the LSC function block and the PSC 
   function block are reserved, the LSR shall be identified as a PSC+LSC
   router that has no OLSP termination capability. If the PSC function 
   block is in a failure state, the LSR shall be identified as a PSC+LSC
   router that has no usable PSC.





Imajuku                                                        [Page 4]





Internet Draft       draft-imajuku-ml-routing-01.txt   28 February 2002


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



3. Multi-layer routing aspects


   In this section, we explain the routing aspects of a generic LSP+OLSP
   multi-layer network comprising LSRs with only LSC and PSC+LSC.
   In such multi-layer network, an LSP layer has LSP switching capability
   through the combination of PSC-LSRs and PSC+LSC-LSRs. On the other 
   hand, an OLSP layer has OLSP switching capability through the 
   combination of LSC-LSRs and PSC+LSC-LSRs. Therefore, the LSR with 
   PSC+LSC shall have both layers' link states and network topology data
   to realize both LSP and OLSP route selection. To provide the route 
   selection functionality, the LSR shall discriminate link state data 
   as to which layer they belong. Path route selection of LSPs and OLSPs
   shall be done with reference to link the state data corresponding to
   each layer.


   The link state of an existing OLSP within the multi-layer GMPLS 
   network can be advertised as a point to point link by using 
   conventional Router LSA in the case of OSPF. This enables the 
   conventional IP routers, which are connected to the multi-layer GMPLS
   network, to realize an IP network plane topology within the network.



Imajuku                                                        [Page 5]





Internet Draft       draft-imajuku-ml-routing-01.txt   28 February 2002


   Alternatively, the link state of existing OLSPs can be advertised in 
   conformance with the concept of FA-LSPs [LSP-HIER]. The OLSP can be 
   identified as the links forming "forwarding adjacency" (FA) between 
   LSRs connected by the OLSP. The corresponding LSA of the OLSP 
   (FA-OLSP) shall contain the interface switching capability 
   descriptor, which indicates the OLSP being terminated by PSCs, and
   information about this LSA is used to configure LSP layer network 
   topology. The forwarding of IP packets or LSPs shall be done by using
   the next-hop database created from this network topology data.


   The link state of existing fiber-links can be advertised by conforming
   to the concept of TE extension to routing protocols [TE-OSPF]
   -[TE-ISIS]. The fiber links connected to LSRs are identified as 
   TE-links that forms "routing adjacency" between LSRs. The 
   corresponding LSA of the TE-Fiber Link shall contain the interface 
   switching capability descriptor, which indicates the fiber link being
   terminated by LSCs, and information about this LSA is used to 
   configure OLSP layer network topology. The routing of OLSPs shall be 
   done by using the next-hop database created from this network 
   topology data.


   Also, these LSRs with integrated PSC+LSC switching capabilities 
   shall be required to advertise resource information in terms of 
   switching capability. The reservation capability of the integrated
   switching node capability shall be varied to match the state of 
   resource utilization as discussed in the previous section. The route 
   of OLSPs can be calculated by the selection of LSCs that have OLSP 
   forwarding or termination capability and fiber links that have 
   unreserved wavelength channels.


   Thus, the LSR can have multi-layer routing capability that 
   enables IP packet forwarding routes to be constructed considering 
   both existing OLSP and fiber-link state. If the unused bandwidth of 
   each OLSP is insufficient, a new OLSP can be automatically set-up in
   response to an IP-traffic surge or LSP setup calls. This means that 
   the LSR can realize the IP-centric flexible Photonic network 
   essential to the next generation large capacity backbone network.



4. Enhancements to interface switching capabilities descriptor

   The draft of [GMPLS-OSPF] defines the Interface Switching Capability 



Imajuku                                                        [Page 6]





Internet Draft       draft-imajuku-ml-routing-01.txt   28 February 2002


   Descriptor with a sub-TLV of the Link TLV with type 15. The length 
   is the length of the value field in octets.


   The Switching Capability (Switching Cap) 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)


   If there is no Interface Switching Capability Descriptor for an 
   interface, the interface is assumed to be packet-switch capable 
   (PSC-1).

   Interface Switching Capability Descriptors present a new constraint 
   for LSP path computation. 

   The detail extensions to Interface Switching Capability Descriptor
   for integrated PSC/LSC LSR will be discussed in the next version of 
   this document.

   The Switching Cap field for integrated multi-layer LSRs: TBD.

   The format of the value field: TBD.


5. Security Considerations


   Security issues are not discussed in this draft.


6. References

   [Shimano01] K. Shimano, A. Imaoka, Y. Takigawa, and K. -I. Sato, 
   "MPLambdaS Demonstration Employing Photonic Routers (256X256 OLSPS) 
   To Integrate Optical and IP Networks," National Fiber Optic 
   Engineers Conf. 2001 Tech.Proc. p. 5.



Imajuku                                                        [Page 7]





Internet Draft       draft-imajuku-ml-routing-01.txt   28 February 2002





   [Oki02] E. Oki, K. Shiomoto, S. Okamoto, W. Imajuku, and N. Yamanaka,
   A heuristic-based multi-layer 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-01.txt (work in progress), 6/01.


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


   [OKI-OLI] "Requirements of optical link-state information for traffic
   engineering," draft-oki-ipo-optlink-req-00.txt, 02/02.


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


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


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



7. Author information

   Wataru Imajuku
   NTT Network Innovation Laboratories
   1-1 Hikari-no-oka,
   Yokosuka, Kanagawa, 239-0847 Japan
   Email: imajyuku@exa.onlab.ntt.co.jp


   Eiji Oki
   NTT Network Innovation Laboratories



Imajuku                                                        [Page 8]





Internet Draft       draft-imajuku-ml-routing-01.txt   28 February 2002


   3-9-11 Midori-cho,
   Musashino-shi, Tokyo 180-8585, Japan
   Phone: +81 422 59 3441
   Fax: +81 422 59 6387
   Email: 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
   Email: shiomoto.kohei@lab.ntt.co.jp


   Satoru Okamoto
   NTT Network Innovation Laboratories
   1-1 Hikari-no-oka,
   Yokosuka, Kanagawa, 239-0847 Japan
   Email: okamoto@exa.onlab.ntt.co.jp




























Imajuku                                                        [Page 9]