One document matched: draft-imajuku-ccamp-rtg-switching-constraint-01.txt
Differences from draft-imajuku-ccamp-rtg-switching-constraint-00.txt
CCAMP working Group W. Imajuku
Internet-Draft Y. Sone
Updates: RFC 4202 NTT
Proposed Status: Standards Track I. Nishioka
Expires: April 23, 2007 NEC
October 23 2006
Routing Extensions to Support Network Elements with Switching Constraint
draft-imajuku-ccamp-rtg-switching-constraint-01.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
Ta
sk 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 April 23, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document proposes routing extensions in support of carrying
switching constraint information in corresponding link state
information for Generalized Multi-Protocol Label Switching (GM
PLS).
With the proposed extension, GMPLS routing protocols can handle
network elements with blocking switch architecture.
Table of Contents
Imajuku, Sone, Nishioka Expires April 23, 2007 [Page 1]
draft-imajuku-ccamp-rtg-switching-constraint-01.txt October 2006
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 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
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 further enhances the routing extensions
required to support GMPLS Traffic Engineering (TE) over network
element
s with blocking switch architecture.
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 direction 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 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 enhance the routing protocol
such that it supports the carrying of switching constraint
information pertaining to the network elements with blocking switch
architecture. The constraint information of each switch is carried
within the link state information of Traffic Engineering (TE) links.
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, Sone, Nishioka Expires April 23, 2007 [Page 2]
draft-imajuku-ccamp-rtg-switching-constraint-01.txt October 2006
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 mechanis
m [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, Sone, Nishioka Expires April 23, 2007 [Page 3]
draft-imajuku-ccamp-rtg-switching-constraint-01.txt October 2006
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 als
o 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 o
utside the ROADM domain assign a ROADM
Imajuku, Sone, Nishioka Expires April 23, 2007 [Page 4]
draft-imajuku-ccamp-rtg-switching-constraint-01.txt October 2006
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 ex
tended 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. Also,
note that it is essential to share switching constraint information
pertaining to each node within the optical network domain in order for
the border nodes to advertise the virtual TE links to other network
domains.
5. Compatibility Iss
ues
There should be no interoperability issues with routers that do not
implement these extensions, as the Opaque LSAs will be silently
ignored.
The result of having routers that do not implement these extensions
is that the traffic engineering topology will be missing pieces.
However, if the topology is connected, TE paths can still be
calculated and ought to work.
Imajuku, Sone, Nishioka Expires April 23, 2007 [Page 5]
draft-imajuku-ccamp-rtg-switching-constraint-01.txt October 2006
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
Extension
s 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 Tunne
ls",
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, Sone, Nishioka Expires April 23, 2007 [Page 6]
draft-imajuku-ccamp-rtg-switching-constraint-01.txt October 2006
work in progress.
9. Acknowledgements
The authors would like to thank Eiji Oki, Tomonori Takeda, A
kira
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
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
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
Imajuku, Sone, Nishioka Expires April 23, 2007 [Page 7]
draft-imajuku-ccamp-rtg-switching-constraint-01.txt October 2006
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Imajuku, Sone, Nishioka Expires April 23, 2007 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-23 17:26:16 |