One document matched: draft-imajuku-ccamp-rtg-switching-constraint-00.txt
CCAMP working Group W. Imajuku
Internet-Draft Y. Sone
Expires: October 16, 2006 NTT
I. Nishioka
NEC
October 16 2006
Routing Extensions to support network elements with switching constraint
draft-imajuku-ccamp-rtg-switching-constraint-00.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 April 16, 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 (GMPLS).
With the proposed extension, GMPLS routing protocols can handle
the network elements with some blocking constraints.
Imajuku, et al. Expires April 16, 2007 [Page 1]
draft-imajuku-ccamp-rtg-switching-constraint-00.txt October 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 2
3. Problem Statements . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Problem Statements . . . . . . . . . . . . . . . . . . . 3
3.2. Example of Problems . . . . . . . . . . . . . . . . . . . 3
3.3. Comments on necessity of extension . . . . . . . . . . . 4
4. Proposal for GMPLS Routing Enhancement . . . . . . . . . . . . 4
5. Compatibility Issues . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . .. . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative references . . . . . . . . . . . . . . . . . . 5
8.2. Informative references . . . . . . . . . . . . . . . . . . 5
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 6
Intellectual Property and Copyright Statements . . . . . . . . . . 6
1. Introduction
The routing protocol extensions so far have been made for Generalized
Multi-Protocol Switching (GMPLS)[OSPF-TE],[GMPLS-ROUTING],[GMPLS-OSPF].
This document enhances the routing extensions required to support
GMPLS Traffic Engineering (TE) over the network elements with blocking
constraints.
Reconfigurable optical add/drop Multiplexer (ROADM) is one of the
network element which employs the blocking switch architecture widely
used in commercialized networks. The ROADM has switching constraints
in the selectivity of direction when adding/dropping a lambda path
from/to a user network interface (UNI) port. The lambda path added
from each UNI port is restricted to either east or west bound of the
ROADM ring. Similarly, the drop of lambda path to the UNI port also
has constraint in the selectivity of the UNI port.
The objective of this document is to enhance the routing protocol
in support of carrying switching constraint information of the
network elements with blocking constraints. 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 et al. Expires April 16, 2007 [Page 2]
draft-imajuku-ccamp-rtg-switching-constraint-00.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 blocking switch architecture to reduce
the cost of switch fabric or wavelength converters. In particular,
the ROADM, which has already been commercially deployed, employs
unique switch architecture having constraint in TE link selectivity,
while the OXC without the wavelength converters has constraint in
wavelength label selectivity.
For the constraint in wavelength label selectivity, GMPLS has
specification to control the label allocation mechanism for
Label Switch Paths (LSPs) based on signaling mechanism [RFC3471],
[RFC3473]. To the contrary, for the constraint in TE link
selectivity, there is no specification at this moment.
To combat with the issue of the constraint in TE link selectivity,
it is obvious that an extension to GMPLS routing mechanism is
essential for all network elements in a domain to understand which
TE link can be selectable to forward LSPs at the network elements
having the constraint.
3.2. Example of Problem
Figure shows an typical example of ROADM ring network to explain the
constraint in TE link selectivity. Assuming that each ROADM switches
optical signals (LSPs) transparently. The UNI ports of each ROADM
are grouped to gwesth and geasth ports. In this network, a lambda
LSP added from a UNI west port can not be dropped to a UNI gwesth
ports at other nodes, and it is also same in the case of vice versa.
For example, a lambda LSP added from UNI port w1 of ROADM #1 can not
be dropped to UNI port w1 or w2 of ROADM #2, #3 and #4. Similarly, a
lambda LSP added from UNI port e1 of ROADM #1 can not be dropped to
UNI port e1 or e2 of ROADM #2, #3 and #4.
_________ _________
| | TE #1-E | | TE #2-E
==========|ROADM #1|==============|ROADM #2|==========
|| TE #1-W |_________| TE #2-W |_________| ||
|| | | | | | | | | ||
|| UNI w1 w2 e1 e2 UNI w1 w2 e1 e2 ||
|| ||
|| ||
|| _________ _________ ||
|| | | TE #4-W | | TE #3-W ||
==========|ROADM #4|==============|ROADM #3|==========
TE #4-E |_________| TE #3-E |_________|
| | | | | | | |
UNI e1 e2 w1 w2 UNI e1 e2 w1 w2
Imajuku et al. Expires April 16, 2007 [Page 3]
draft-imajuku-ccamp-rtg-switching-constraint-00.txt October 2006
3.3. Comments on necessity of extension
The problem statement described in the previous section is not
so critical if the network is single ROADM ring network. In such case,
the routing of LSPs can be performed based on static routing without
using any routing protocols.
Employment of inter-domain routing architecture can also be one of
solution. By separating ROADM rings from a GMPLS routing domain,
the nodes outside ROADM domain assign ROADM node ID or boundary node
adjacent to the ROADM domain with loose Explicit Route Object (ERO)
to forward Lambda LSP. Then, each ROADM node perform loose hop
expansion to forward the lambda LSP toward destination [RFC3209],
[per-domain-calc].
The case which essentially requires the extension to GMPLS routing
mechanism is the case that 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 domain also required
to consider the constraint in TE link selectivity at the ROADM nodes
when creating the Lambda LSP.
4. Proposal for GMPLS Routing Enhancement
This section proposes a possible solution to advertise the constraint
in TE link selectivity. The extended sub-TLVs are indicates 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:
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
5. Compatibility Issues
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 et al. Expires April 16, 2007 [Page 4]
draft-imajuku-ccamp-rtg-switching-constraint-00.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
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.
8.2 Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997
[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.
[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.
Imajuku et al. Expires April 16, 2007 [Page 5]
draft-imajuku-ccamp-rtg-switching-constraint-00.txt October 2006
9. Acknowledgements
The authors would like to thank Eiji Oki and Tomonori Takeda 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
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
Imajuku et al. Expires April 16, 2007 [Page 6]
draft-imajuku-ccamp-rtg-switching-constraint-00.txt October 2006
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 et al. Expires April 16, 2007 [Page 7]
| PAFTECH AB 2003-2026 | 2026-04-23 17:31:37 |