Network Working Group Sugang Xu
Internet-Draft Hiroaki Harai
Intended status: Standards Track NICT
Expires: May 2008 Daniel King
Aria Networks
November 12 2007
Extensions to GMPLS RSVP-TE for Bidirectional Lightpath
with the Same Wavelength
draft-xu-rsvpte-bidir-wave-01
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.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
For bidirectional lightpaths provisioning, in the case of optical nodes
that do not support wavelength conversion, it would be necessary to use
the same wavelength along the route on each direction. In certain
optical network scenarios, the use of the same wavelength on both
directions would be advantageous. For instance, some ROADMs may
add/drop the same wavelength simultaneously. In other cases, the users'
optical end nodes are equipped with fixed-wavelength transponders.
This document describes extensions to RSVP-TE signaling for
bidirectional wavelength lightpaths that require the same wavelength on
both directions. By using an LSP_ATTRIBUTES object defined in [RFC4420],
the extensions enable the new type lightpaths to support the low cost
configuration at users' optical end nodes.
Xu et al. Expires May 2008 [Page 1]
Internet-Draft draft-xu-rsvpte-bidir-wave-01.txt November 2007
Table of Contents
1. Conventions Used in This Document................................2
2. Terminology......................................................2
3. Introduction and Problem Statement...............................3
3.1 Port-remapping Problem..........................................3
3.2 Port-remapping with OXC.........................................6
4. Avoiding Port-remapping Problem..................................7
4.1 Bidirectional Lightpath using Same Wavelength on Both Directions.7
4.2 Inefficient Alternate Solutions.................................7
4.2.1 Unidirectional Lightpaths with the Same Wavelength............7
4.2.2 Upstream Label Set and Label Set..............................7
5. Using LSP_ATTRIBUTES Object......................................8
6. Label Set Object and Bidirectional Lightpath.....................8
6.1 Procedure.......................................................8
7. Backward Compatibility Considerations............................9
8. Wavelength Assignment Issue..................................... 9
9. Link Bundling Issue.............................................10
10. IANA Considerations............................................10
11. Security Considerations........................................10
12. Acknowledgements...............................................10
13. Normative References...........................................10
14. Authors' Addresses.............................................10
1. 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 [RFC2119].
2. Terminology
The readers are assumed to be familiar with the terminology defined
in [RFC3471], [RFC3473] and [RFC4420].
The term "node" in this document, when used in the context of the
procedure description in section 6, refers to the GMPLS node which
is the signaling controller in the control plane.
The term "receiver" in this document indicates a GMPLS node, which
receives messages from its GMPLS neighbor nodes.
The term "optical transmitter" in this document is a device that has
both a laser tuned on certain wavelength and electronic components,
which converts electronic signals into optical signals.
The term "optical responder" in this document is a device that has
both optical and electronic components. It detects optical signals
and converts optical signals into electronic signals.
The term "optical transponder" in this document is a device that has
both an optical transmitter and an optical responder.
The term "optical end node" in this document is the end of a wavelength
Xu et al. Expires May 2008 [Page 2]
Internet-Draft draft-xu-rsvpte-bidir-wave-01.txt November 2007
(optical lambdas) lightpath in the data plane. It may be equipped with
some optical/electronic devices such as wavelength
multiplexers/demultiplexer (e.g. arrayed wavelength grating (AWG)),
optical transponder, etc., which are employed to transmit/terminate the
optical signals for data transmission.
The term "wavelength-routed network" in this document is a network
that consists of transit nodes which may be equipped with wavelength
selective switching elements such as reconfigurable optical add/drop
multiplexer (ROADM) or optical cross-connect (OXC), and optical end
nodes at edges. Wavelength lightpaths between optical end nodes can
be established across the network.
3. Introduction and Problem Statement
With the Lambda Switch (LSC) support defined in GMPLS [RFC3471] and
RSVP-TE signaling [RFC3473], by properly configuring the wavelength
selective switching elements such as ROADMs or OXCs at the transit
nodes, both unidirectional and bidirectional wavelength (optical
lambdas) lightpaths can be established in a wavelength-routed network.
To provide high-performance full-duplex transmission links between
users' optical end nodes (e.g. computers, switches and routers, which
are equipped with the necessary optical transmitters and responders)
directly, bidirectional lightpaths should be established between users'
optical end nodes.
This document considers the various scenarios where bidirectional
lightpaths would be required for users' direct full-duplex end-end
communications. By using the LSP_ATTRIBUTES object defined in [RFC4420],
new extensions to RSVP-TE signaling are introduced. These extensions
enable the lightpath to support the required configuration to enable the
same wavelength to be used on both directions between the users' optical
end nodes.
The extensions in this document would be applied to various scenarios.
For example, only a specific wavelength among the multiplexed
wavelengths could be added/dropped to an optical end node. In another
case, some type of ROADMs may add/drop the same wavelength
simultaneously. In these cases, using the same wavelength on both
directions is a solution. Another problem that takes into account users'
convenience, avoiding port-remapping, is stated as follows.
3.1 Port-remapping Problem
In the context of CI-incapable [RFC3471] wavelength-routed networks,
where the nodes in the networks cannot support wavelength conversion,
the same wavelength on each link along a unidirectional lightpath
should be reserved. According to the definition in [RFC3471], a
bidirectional lightpath can be seen as a pair of unidirectional
lightpaths, which are provisioned along the same route simultaneously
by the RSVP-TE signaling with Upstream Label and Label Set Objects in
the messages [RFC3473].
A previously defined bidirectional lightpath does not
Xu et al. Expires May 2008 [Page 3]
Internet-Draft draft-xu-rsvpte-bidir-wave-01.txt November 2007
necessarily require the same wavelength on both directions.
In consequence, the selection of the upstream and downstream labels
are independent. That is to say, when establishing a bidirectional
wavelength lightpath, the wavelengths on both directions selected
using RSVP-TE may be different. This may result in a
wavelength-routed network specific port-remapping problem at both
ends of the bidirectional lightpath. This problem occurs in the
following situations:
(1) Fixed wavelength multiplexer/demultiplexer like AWGs may be employed
at each node. Each incoming and outgoing wavelength is with a dedicated
fixed port of AWG. For example, wavelength lambda 1 is on port 1, and
wavelength lambda 2 is on port 2, and so on. See Fig.3.1.1.
+--+
| |---> lambda 1: port 1
-->| |---> lambda 2: port 2
| |---> lambda 3: port 3
+--+
A. AWG Demultiplexer case.
+--+
| |<--- lambda 1: port 1
<--| |<--- lambda 2: port 2
| |<--- lambda 3: port 3
+--+
B. AWG Multiplexer case.
Fig.3.1.1. The fixed wavelength-port mapping of AWG
Multiplexer/Demultiplexer.
(2) Compared to a wavelength-tunable optical transponder array, low cost
fixed-tuned optical transponder array may be employed at the edge node.
In an optical transponder, the optical responder is bound with the
transmitter. Each of the optical transmitters and responders are
physically connected to one port of AWG or OXC according to the
configuration. See Fig.3.1.2.
+--+ +----+
| |<---lambda 1---| T1 |
<--| |<---lambda 2---| T2 |
| |<---lambda 3---| T3 |
+--+ +----+
AWG Multiplexer optical transmitter array
A. The configuration with the optical transmitters connecting AWG.
+--+ +----+
| |---lambda 1--->| R1 |
-->| |---lambda 2--->| R2 |
| |---lambda 3--->| R3 |
+--+ +----+
AWG Demultiplexer optical responder array
B. One possible configuration with the optical responders connecting
AWG.
Xu et al. Expires May 2008 [Page 4]
Internet-Draft draft-xu-rsvpte-bidir-wave-01.txt November 2007
+--+ +-----+ +----+
| |--->| |--->| R1 |
-->| |--->| OXC |--->| R2 |
| |--->| |--->| R3 |
+--+ +-----+ +----+
AWG Demultiplexer optical responder array
C. One possible configuration with the optical responders connecting
OXC.
Fig.3.1.2. The fixed optical transmitter/responder- AGW/OXC port
mapping at the optical end nodes.
Consider a bidirectional lightpath with different wavelengths on two
directions. The optical transmitter of which output wavelength is the
same as the outgoing-wavelength (say lambda 1) is chosen first for
using the lightpath. Then, the optical responder attached to that
transmitter should be selected for receiving the incoming wavelength
(say lambda 2). The responder generally can receive any of different
wavelengths. Therefore, if another bidirectional lightpath is
assigned the same outgoing wavelength (lambda 1) but with a different
incoming wavelength (say lambda 3), the same transmitter and responder
pair is selected. See Fig.3.1.3.
+----+
<-lambda 1---| T1 |
+----+
A. Optical transmitter T1 sends optical signals on lambda 1.
+----+
-lambda 2--->| R1 |
+----+
B. Optical responder R1 receives optical signals on lambda 2 for one
bidirectional lightpath.
+----+
-lambda 3--->| R1 |
+----+
C. Optical responder R1 can receive optical signals on lambda 3 for
another bidirectional lightpath.
Fig.3.1.3. Transmitter sends optical signals on the fixed-tuned
wavelength; the responder can receive data on different wavelengths.
However, the communication using the transponder and the
bidirectional lightpath with different wavelengths will not succeed
under the situations (1) and (2) mentioned above. Remember the fixed
port mapping that each incoming wavelength is fixed on a unique port
of AWG due to the situation (1), and the optical responder is also
fixedly connected to a unique port of AWG or OXC due to the situation
(2). Conversely, the incoming wavelength may change every
lightpath (see lambda 2 and lambda 3 in the above case) for the same
outgoing wavelength (lambda 1). The current incoming wavelength
(lambda 3) is not on the port of AWG to which the optical responder
connects originally (lambda 2), see Fig. 3.1.4. To connect the
Xu et al. Expires May 2008 [Page 5]
Internet-Draft draft-xu-rsvpte-bidir-wave-01.txt November 2007
optical responder to the proper port on which the incoming wavelength
is, even in different outgoing wavelengths, a port-remapping process
between the optical responder and AWG ports may be required.
+--+ +----+
| |<---lambda 1---| T1 |
<--| |<---lambda 2---| T2 |
| |<---lambda 3---| T3 |
+--+ +----+
AWG Multiplexer
A. Optical transmitter T1 sends optical signals on lambda 1.
+--+
| |-- +----+
-->| |--lambda2---->| R1 |
| |--lambda3-X +----+
+--+
AWG Demultiplexer
B. Optical responder R1 cannot receive optical signals on lambda 3
due to the fixed port mapping, in case of that R1 is physically
connected to the port 2 of lambda 2 on AWG.
Fig. 3.1.4. Port-remapping problem occurs due to the fixed
port-mapping between the optical responder and AWG port.
3.2 Port-remapping with OXC
The port-remapping capability depends on the system configurations
at users' optical end nodes. For example, an OXC may be employed
to switch the incoming wavelength from the port of AWG to the port
which the optical responder is connected physically, see Fig. 3.2.1.
However, equipping users' optical end nodes with OXCs introduces
extra costs. There exists a trade-off between port-remapping
capability and cost/system complexity.
+--+ +-------+ +----+
| |-lambda 1-->| /--|--->| R1 |
-->| |-lambda 2-->|---/ |--->| R2 |
| |-lambda 3-->| OXC |--->| R3 |
+--+ +-------+ +----+
AWG Demultiplexer
A. The optical responder R1 can receive the optical signals on lambda
2.
+--+ +-------+ +----+
| |-lambda 1-->| /---|--->| R1 |
-->| |-lambda 2-->| / |--->| R2 |
| |-lambda 3-->|-/ OXC |--->| R3 |
+--+ +-------+ +----+
AWG Demultiplexer
B. The optical responder R1 can receive the optical signals on lambda
3.
Fig.3.2.1. The port-remapping capability provided by OXC.
Xu et al. Expires May 2008 [Page 6]
Internet-Draft draft-xu-rsvpte-bidir-wave-01.txt November 2007
Users have various types of optical end node configurations to
choose from. Some configurations such as those equipped with OXCs might
provide flexibility but could be costly and potentially complicated.
Equally, while other configurations without OXCs might lack the
flexibility they may be inexpensive and easy to use and maintain.
4. Avoiding Port-remapping Problem
Which solution will be employed depends on the considerations of the
flexibility and cost/complexity trade-off. If users do not have
port-remapping capability at optical end nodes, then it is
necessary to avoid the port-remapping, and find a feasible approach
to provide users full-duplex transmission capability with
bidirectional lightpath.
4.1 Bidirectional Lightpath using Same Wavelength on Both Directions
A feasible approach is to establish a bidirectional lightpath with
the same wavelength on both directions. At the optical end node,
fixed-tuned transponder array is connected to the proper ports of AWG
according to the wavelength. Optical transmitter and responder pair
connecting the selected outgoing and incoming wavelength ports of AWG
will be assigned to the bidirectional lightpath. In this document,
the bidirectional lightpath with the same wavelength on both
directions is introduced as a complementary lightpath type.
4.2 Inefficient Alternate Solutions
4.2.1 Unidirectional Lightpaths with the Same Wavelength
Separately establishing two unidirectional lightpaths on different
directions using the same wavelength between two optical end nodes might
be an approach to support users' full-duplex transmission requirement.
The same wavelength requirement could be achieved by sequentially
scanning the wavelengths' availability on both directions. Establish
one-way lightpath first and verify the availability of the same
wavelength on another lightpath. If the wavelength is not available
on both directions, release the former unidirectional lightpath, and
repeat this process with a next wavelength, until an available
wavelength is found on both directions. However, this solution is
inefficient because it might be time consuming during the scan process
of the wavelength availability verification.
4.2.2 Upstream Label Set and Label Set
Another approach is to extent the RSVP-TE signaling by defining an
Upstream Label Set object, and to select the common free wavelengths
along the upstream and downstream lightpaths. Although it inherits
the idea of Upstream Label from traditional bidirectional LSP, it is
still not a neat solution and is inefficient.
The simplest way is to only define an extension to the processing of
Label Set [RFC3473], and leave the other processes untouched. The
issues related to this new functionality including an LSP_ATTRIBUTES
Xu et al. Expires May 2008 [Page 7]
Internet-Draft draft-xu-rsvpte-bidir-wave-01.txt November 2007
object defined in [RFC4420] and the new procedure are described in
the following sections.
5. Using LSP_ATTRIBUTES Object
To trigger the new functionality at each GMPLS node, it is necessary
to notify the receiver the new type lightpath request. One
multi-purpose flag/attribute parameter container object called
LSP_ATTRIBUTES object and related mechanism defined in [RFC4420] meet
this requirement. One bit in Attributes Flags TLV which indicates the
new type lightpath, say, the bidirectional same wavelength lightpath
will be present in an LSP_ATTRIBUTES object. Please refer to
[RFC4420] for detailed descriptions of the Flag and related issues.
6. Label Set Object and Bidirectional Lightpath
Considering the system configuration mentioned above, it is needed
to add a new function into RSVP-TE to support bidirectional lightpath
with same wavelength on both directions.
6.1 Procedure
The lightpath setup procedure is described below:
(1) Ingress node adds the new type lightpath indication in an
LSP_ATTRIBUTES object. It is propagated in the Path message in the
same way as that of a Label Set object for downstream;
(2) On reception of a Path message containing both the new type
lightpath indication in an LSP_ATTRIBUTES object and Label Set object,
the receiver checks the local LSP database to see if the Label Set
TLVs are acceptable on both directions jointly. If there are
acceptable wavelengths, then copy the values of them into new Label
Set TLVs, and forward the Path message to the downstream node.
Otherwise the Path message will be terminated, and a PathErr message
with a "Routing problem/Label Set" indication will be generated;
(3) On reception of a Path message containing both such a new type
lightpath indication in an LSP_ATTRIBUTES object and an Upstream Label
object, the receiver MUST terminate the Path message using a PathErr
message with Error Code "Unknown Attributes TLV" and Error Value set
to the value of the new type lightpath TLV type code;
(4) On reception of a Path message containing both the new type
lightpath indication in an LSP_ATTRIBUTES object and Label Set object,
the egress node verifies whether the Label Set TLVs are acceptable,
if one or more wavelengths are available on both directions, then any
one available wavelength could be selected. A Resv message is
generated and propagated to upstream node;
(5) When a Resv message is received at an intermediate node, if it is a
new type lightpath, the intermediate node allocates the label to
interfaces on both directions and update internal database for this
bidirectional same wavelength lightpath, then configures the local ROADM
Xu et al. Expires May 2008 [Page 8]
Internet-Draft draft-xu-rsvpte-bidir-wave-01.txt November 2007
or OXC on both directions.
Except the procedure related to Label Set object, the other processes
will be left untouched.
7. Backward Compatibility Considerations
Due to the introduction of new processing on Label Set object, it is
required that each node in the lightpath is able to recognize the new
type lightpath indication Flag carried by an LSP_ATTRIBUTES object,
and deal with the new Label Set operation correctly. It is noted that
this new extension is not backward compatible.
According to the descriptions in [RFC4420], an LSR that does not
recognize a TLV type code carried in this object MUST reject the Path
message using a PathErr message with Error Code "Unknown Attributes
TLV" and Error Value set to the value of the Attributes Flags TLV type
code.
An LSR that does not recognize a bit set in the Attributes Flags TLV
MUST reject the Path message using a PathErr message with Error Code
"Unknown Attributes Bit" and Error Value set to the bit number of the
new type lightpath Flag in the Attributes Flags.
The reader is referred to the detailed backward compatibility
considerations expressed in [RFC4420].
8. Wavelength Assignment Issue
This signaling approach can be used for both combined routing and
wavelength assignment and separate routing and wavelength assignment
approaches, with and without Path Computation Element (PCE) support.
This signaling provides a unified signaling solution for different
scenarios.
a) Given a routing and wavelength assignment solution e.g. derived from
a PCE, an ingress node can put one wavelength label in Label set or a
Suggested label object to specify the wavelength.
b) Given only routing solution e.g. from a PCE, an ingress node can set
one or more available wavelength label objects in Label set, and let the
egress node resolve the wavelength assignment in a distributed fashion.
c) Because this signaling solution can resolve wavelength assignment
problem itself, even without interaction with a PCE, by using an
explicit route e.g. manually, it is still possible to establish a
bidirectional lightpath. For example, a second lightpath is requested
between the same node pair of the previously established lightpath, e.g.
for quick recovery from failures, bidirectional signaling may negate a
PCE request. LSP set up time may also be reduced. Moreover, compared to
other crank back signaling approaches shown above, for distributed
wavelength assignment, this approach would have a lower blocking
probability and a shorter provisioning time.
Xu et al. Expires May 2008 [Page 9]
Internet-Draft draft-xu-rsvpte-bidir-wave-01.txt November 2007
9. Link Bundling Issue
PCE path computation problems may occur when computing bidirectional
lightpaths. In a GMPLS network where multiple component links are
aggregated into a link bundle and advertised as a single bidirectional
TE link, the Traffic Engineering Database (TED) may indicate the
availability of a particular lambda in both directions on the TE link.
However, it may actually be the case that the lambda is only available
in one direction on one component link, and the other direction is only
available on a different component link. In this scenario, creating an
end-to-end path that uses the same lambdas and the same component links
in both directions presents a PCE path computation problem. This
signaling can be used to verify the solution received from PCE.
10. IANA Considerations
One bit in Attributes Flags TLV which indicates the new type lightpath,
say, the bidirectional same wavelength lightpath will be present in an
LSP_ATTRIBUTES object. For example, one possible position in Attributes
Flags TLV is suggested to be the 9th bit. The actions for IANA are under
discussion, and will be added to the document in a later draft.
11. Security Considerations
This document adds new procedure related only to Label Set object at
each node. It does not introduce any new direct security issues, and
the reader is referred to the security considerations expressed in
[RFC3473] and [RFC4420].
12. Acknowledgements
The authors would like to thank to Adrian Farrel for helpful comments
and feedback.
13. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3471] Berger, L. (Ed.), "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC3473] Berger, L. (Ed.), "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC4420] A. Farrel, et al., "Encoding of Attributes for
Multiprotocol Label Switching (MPLS) Label Switched Path (LSP)
Establishment Using Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) ", RFC 4420, February 2006
14. Authors' Addresses
Xu et al. Expires May 2008 [Page 10]
Internet-Draft draft-xu-rsvpte-bidir-wave-01.txt November 2007
Sugang Xu
National Institute of Information and Communications Technology
4-2-1 Nukui-Kitamachi, Koganei, Tokyo, 184-8795 Japan
Phone: +81 42-327-6927
Email: xsg@nict.go.jp
Hiroaki Harai
National Institute of Information and Communications Technology
4-2-1 Nukui-Kitamachi, Koganei, Tokyo, 184-8795 Japan
Phone: +81 42-327-5418
Email: harai@nict.go.jp
Daniel King
Aria Networks
44/45 Market Place, Chippenham, SN15 3HU, United Kingdom
Phone: +44 7790 775187
Email: daniel.king@aria-networks.com
Full 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.
Intellectual Property
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.
Xu et al. Expires May 2008 [Page 11]
Internet-Draft draft-xu-rsvpte-bidir-wave-01.txt November 2007
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.
Acknowledgements
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Xu et al. Expires May 2008 [Page 12]