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

Versions: 00 01 02

CCAMP working Group                                           W. Imajuku
Internet-Draft                                                   Y. Sone
Updates: RFC 4202                                                    NTT
Proposed Status: Standards Track                             I. Nishioka
Expires January 2008                                                 NEC
                                                                 S. Seno
                                         Mitsubishi Electric Corporation
                                                               July 2007


Routing Extensions to Support Network Elements with Switching Constraint
           draft-imajuku-ccamp-rtg-switching-constraint-02.txt



Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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.

   This Internet-Draft will expire on January 8, 2008.


Abstract

   This document shares problem statements of the routing of optical
   Label Switched Paths(LSPs) over network elements with blocking switch
   architecture in fiber port selectivity. Also, this document provides a
   direction of solution to take into account the switching constraint
   within the scope of GMPLS Traffic Engineering (TE) over network elements
   with blocking switch architecture in fiber port selectivity in addition
   to wavelength selectivity.

Table of Contents

Imajuku, Nishioka, Seno        Expires January 2008                  [Page 1]


draft-imajuku-ccamp-rtg-switching-constraint-02.txt          July    2007


   1.  Introduction   . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Conventions used in this document  . . . . . . . . . . . . . .  2
   3.  Problem Statements . . . . . . . . . . . . . . . . . . . . . .  3
     3.1.  Problem Statements . . . . . . . . . . . . . . . . . . . .  3
     3.2.  Problem Example  . . . . . . . . . . . . . . . . . . . . .  3
     3.3.  Comments on Necessity of Extension . . . . . . . . . . . .  4
   4.  Proposal for GMPLS Routing Enhancement . . . . . . . . . . . .  5
     4.1.  Possible Routing Enhancement . . . . . . . . . . . . . . .  5
     4.2.  Comments on Other Possible Solutions . . . . . . . . . . .  5
   5.  Compatibility and Inter-domain Issues  . . . . . . . . . . . .  5
   6.  Security Considerations. . . . . . . . . . . . . . . . . . . .  6
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  6
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     8.1.  Normative references   . . . . . . . . . . . . . . . . . .  6
     8.2.  Informative references . . . . . . . . . . . . . . . . . .  6
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  7
   10.  Authors' Addresses  . . . . . . . . . . . . . . . . . . . . .  7
   Intellectual Property and Copyright Statements . . . . . . . . . .  7
   Copyright Statement. . . . . . . . . . . . . . . . . . . . . . . .  8


1.  Introduction

   The routing protocol extensions so far have been developed for
   Generalized Multi-Protocol Switching (GMPLS)[OSPF-TE],[GMPLS-ROUTING],
   [GMPLS-OSPF]. This document explains the necessity of routing
   extensions required to support GMPLS Traffic Engineering (TE) over
   network elements with blocking switch architecture in fiber port
   selectivity in addition to wavelength selectivity.

   A reconfigurable optical add/drop multiplexer (ROADM) is a network
   element that employs the blocking switch architecture widely used in
   commercialized networks. The ROADM has switching constraints with
   respect to selecting the fiber port when adding/dropping a lambda path
   from/to a tributary port. The lambda path added from each tributary
   port is restricted to either east or west fiber port of the ROADM ring.
   Similarly, the dropping of a lambda path connected to the tributary
   port also has a constraint with respect to the selection of the
   tributary port.

   The objective of this document is to share problem statement within
   this community and to provide a direction of solution to support the
   routing of Optical Label Switched Paths with blocking switch
   architecture having the constraint of selecting fiber ports.

2.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC 2119
   [RFC2119].

Imajuku, Nishioka, Seno        Expires January 2008                  [Page 2]


draft-imajuku-ccamp-rtg-switching-constraint-02.txt          July    2007


3.  Problem Statements

3.1.  Problem Statements

   Many lambda switch capable (LSC) nodes such as ROADM and Optical
   Cross-Connects (OXC) employ the blocking switch architecture to reduce
   the cost of the switch fabric or wavelength converters. In particular,
   the ROADM, which was already commercially deployed, employs a unique
   switch architecture that has a constraint with respect to the TE link
   selectivity, while the OXC without wavelength converters has a
   constraint with respect to wavelength label selectivity.

   For the wavelength label selectivity constraint, GMPLS has a
   specification to control the label allocation mechanism for Label
   Switch Paths (LSPs) based on the signaling mechanism [RFC3471],
   [RFC3473]. On the contrary, for the TE link selectivity constraint,
   there is currently no specification.

   To address this issue regarding the TE link selectivity constraint,
   it is clear that an extension to the GMPLS routing mechanism is
   essential for all network elements in a domain in order to understand
   which TE link can be selected to forward LSPs at the network elements
   that have the constraint.

3.2.  Problem Example

   Figure shows a typical example using ROADM systems and ROADM ring
   network architecture to illustrate the TE link selectivity constraint.
   In this example, we assume that each ROADM switches optical signals
   (LSPs) transparently and a ROADM system comprises four tributary
   interfaces, i.e., w1, w2, e1, and e2. Lambda LSPs from TE-Wx can only
   be dropped to w1 or w2, and lambda LSPs can only be added from e1 and e2,
   if these LSPs are forwarded to TE-Ex. Similarly, lambda LSPs from TE-Ex
   can only be dropped from e1 or e2, and lambda LSPs can only be added
   from w1 and w2 if these LSPs are forwarded to TE-Wx. Thus, the ports
   for each ROADM are grouped into "west" and "east" ports from the
   viewpoint of TE link selectivity.

               ________________________________________________
              | ROADM     __   __            __   __           |
              |          |Rx| |Rx|          |Tx| |Tx|          |
              |       w1 |__| |__|w2     e1 |__| |__|e2        |
              |          /|\  /|\           \|/  \|/           |
              |         __|____|___       ___|____|__          |
              |   /|->-|           |-->--|           |->-|\    |
              |  | |->-|   Drop    |-->--|    Add    |->-| |   |
         --->----| |->-|           |-->--|           |->-| |---->----
              |  | |->-| switches  |-->--| switches  |->-| |   |
              |   \|->-|___________|-->--|___________|->-|/    |


Imajuku, Nishioka, Seno        Expires January 2008                  [Page 3]


draft-imajuku-ccamp-rtg-switching-constraint-02.txt          July    2007


        TE-Wx |          ___________       ___________         |  TE-Ex
              |    /|-<-|           |--<--|           |-<-|\   |
              |   | |-<-|    Add    |--<--|   Drop    |-<-| |  |
         ----<----| |-<-|           |--<--|           |-<-| |----<---
              |   | |-<-| switches  |--<--| switches  |-<-| |  |
              |    \|-<-|___________|--<--|___________|-<-|/   |
              |          /|\  /|\           \|/  \|/           |
              |           |_   |_            |_   |_           |
              |          |Tx| |Tx|          |Rx| |Rx|          |
              |          |__| |__|          |__| |__|          |
              |           w1   w2            e1   e2           |
              |________________________________________________|


   In a ring network using ROADM systems, a lambda LSP added from a west
   tributary port cannot be dropped to a "west" tributary port at another
   node, and this is also true for the "east" bound case.
   For example, a lambda LSP added from tributary port w1 of ROADM #1
   cannot be dropped to tributary port w1 or w2 of ROADM #2, #3, or #4.
   Similarly, a lambda LSP added from tributary port e1 of ROADM #1
   Cannot be dropped to tributary port e1 or e2 of ROADM #2, #3, or #4.

                     _________                _________
                    |         | TE #1-E      |         | TE #2-E
          ==========|ROADM  #1|==============|ROADM  #2|==========
        ||  TE #1-W |_________|      TE #2-W |_________|          ||
        ||           | |   | |                | |   | |           ||
        ||Tributary w1 w2 e1 e2    Tributary w1 w2 e1 e2          ||
        ||                                                        ||
        ||                                                        ||
        ||           _________                _________           ||
        ||          |         | TE #4-W      |         | TE #3-W  ||
          ==========|ROADM  #4|==============|ROADM  #3|==========
            TE #4-E |_________|      TE #3-E |_________|
                     | |   | |                | |   | |
          Tributary e1 e2 w1 w2    Tributary e1 e2 w1 w2

3.3. Comments on Necessity of Extension

   The problem described in the previous section is not so critical if
   the network comprises a single ROADM ring network. In such a case,
   the routing of LSPs can be performed based on static routing without
   using any routing protocols. Assignment of a destination node ID
   with a loose option in the Explicit Route Object (ERO) of the
   signaling message and execution of loose hop expansion [RFC3209]
   in each ROADM may result in successfully establishing an LSP.

   Employing an inter-domain routing architecture can also be a
   solution [per-domain-calc]. By separating ROADM rings from a GMPLS
   routing domain, the nodes outside the ROADM domain assign a ROADM

Imajuku, Nishioka, Seno        Expires January 2008                  [Page 4]


draft-imajuku-ccamp-rtg-switching-constraint-02.txt          July    2007


   node ID or boundary node adjacent to the ROADM domain with a loose
   ERO to forward the Lambda LSP. Then, each ROADM node performs loose
   hop expansion to forward the lambda LSP toward the destination.

   The case that essentially requires an extension of the GMPLS routing
   mechanism is the case in which the ROADM and other Lambda or Fiber
   Switch capable nodes co-exist in the same routing domain. Packet and
   TDM switch capable nodes attached to such a domain must also consider
   the TE link selectivity constraint at the ROADM nodes when creating a
   Lambda LSP.

4.  Proposal for GMPLS Routing Enhancement

4.1. Possible Routing Enhancement

   This section proposes advertising the TE link selectivity constraint
   as a solution. The extended sub-TLVs indicate the list of selectable
   and/or unselectable TE links from the TE link indicated in sub-TLV
   Type 2 (Link ID).

   The possible extensions to sub-TLV are described below.

   Sub-TLV Type      Length    Name
            TBD    variable    Selectable numbered TE link list
            TBD    variable    Unselectable numberd TE link list
            TBD    variable    Selectable unnumberd TE link list
            TBD    variable    Unselectable unnumberd TE link list

4.2. Comments on Other Possible Solutions

   Employing a virtual TE link model as discussed in L1-VPN WG is also
   a possible solution [l1-vpn-frwk]. An optical network domain that
   has a switching constraint can be modeled as an abstract mesh network.
   Note that this routing architecture requires a hierarchical routing
   mechanism in each border node of the optical network domain.

5.  Inter-domain and Compatibility Issues

   Note that it is essential to share switching constraint information
   pertaining to each node in order for the border nodes to advertise
   abstract information to other network domains.

   Also, note that it is essential to share switching constraint information
   pertaining to each node with the Path Computation Element (PCE), if the
   PCE based inter-domain routing architecture is employed.

   There should be no interoperability issues with routers that do not
   implement these extensions, as the Opaque LSAs will be silently
   ignored.

Imajuku, Nishioka, Seno        Expires January 2008                  [Page 5]


draft-imajuku-ccamp-rtg-switching-constraint-02.txt          July    2007


6.  Security considerations

   TBD

7.  IANA considerations

   TBD

8.  References

8.1 Normative References

   [RFC3630]         Katz, D., Kompella, K., and D. Yeung, "Traffic
                     Engineering (TE) Extensions to OSPF Version 2", RFC
                     3630, September 2003.

   [RFC4202]         Kompella, K., Ed., and Y. Rekhter, Ed., "Routing
                     Extensions in Support of Generalized Multi-Protocol
                     Label Switching (GMPLS)", RFC 4202, October 2005.

   [RFC4203]         Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF
                     Extensions in Support of Generalized Multi-Protocol
                     Label Switching (GMPLS)", RFC 4203, October 2005.

   [RFC3471]         Berger, L., et al, "Generalized Multi-Protocol
                     Label Switching (GMPLS) Signaling Functional
                     Description", RFC 3471, January 2003.

   [RFC3473]         Berger, L., et al, "Generalized Multi-Protocol
                     Label Switching (GMPLS) Signaling Resource
                     ReserVation Protocol-Traffic Engineering (RSVP-TE)
                     Extensions", RFC 3473, January 2003.
   [RFC3209]         Awduche, D., Berger, L., Gan, D., Li, T.,
                     Srinivasan, V. and G. Swallow, "RSVP-TE:
                     Extensions to RSVP for LSP Tunnels",
                     RFC 3209, December 2001.

8.2 Informative References

   [RFC2119]           Bradner, S., "Key words for use in RFCs to
                       Indicate Requirement Levels", BCP 14, RFC 2119,
                       March 1997

   [per-domain-calc]   Vasseur, J. P., Ayyanger, A., Zhang, R., "A Per-
                       domain path computation method for establishing
                       Inter-domain Traffic Engineering (TE) Label
                       Switched Paths (LSPs)", RFC 3471, January 2003.

   [l1-vpn-frwk]       Takeda, T (editor), "Framework and Requirements
                       for Layer 1 Virtual Private Networks",

Imajuku, Nishioka, Seno        Expires January 2008                  [Page 6]


draft-imajuku-ccamp-rtg-switching-constraint-02.txt          July    2007


                       work in progress.

9.  Acknowledgements

   The authors would like to thank Eiji Oki, Tomonori Takeda, Akira
   Nagata, and Akira Chugo for helpful discussion.

10. Authors' Addresses

   Wataru Imajuku
   NTT Network Innovation Laboratories
   1-1 Hikari-no-oka, Yokosuka, Kanagawa 239-0847
   Japan

   Phone: +81 46 859 4315
   Email: imajuku.wataru@lab.ntt.co. jp

   Yoshiaki Sone
   NTT Network Innovation Laboratories
   1-1 Hikari-no-oka, Yokosuka, Kanagawa 239-0847
   Japan

  Phone: +81 46 859 2456
   Email: sone.yoshiaki@lab.ntt.co.jp

   Itaru Nishioka
   NEC Corp.
   1753 Simonumabe, Nakahara-ku, Kawasaki, Kanagawa 211-8666
   Japan

   Phone: +81 44 396 3287
   Email: i-nishioka@cb.jp.nec.com

   Shoichiro Seno
   Mitsubishi Electric Corporation
   5-1-1 Ofuna, Kamakura, Kanagawa 247-8501
   Japan

   Phone: +81 467 41 2881
   Email: Senoo.Shoichiro@dc.MitsubishiElectric.co.jp

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be

Imajuku, Nishioka, Seno        Expires January 2008                  [Page 7]


draft-imajuku-ccamp-rtg-switching-constraint-02.txt          July    2007


   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.




















Imajuku, Nishioka, Seno        Expires January 2008                  [Page 8]


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