One document matched: draft-sorrento-rsvp-bi-osp-00.txt
Network Working Group Dan Guo (Sorrento Networks)
Internet Draft Leah Zhang (Sorrento Networks)
Expiration Date: Jan 2001 James Fu (Sorrento Networks)
Raymond Cheung (Sorrento Networks)
Extensions to RSVP-TE for Bi-directional Optical Path Setup
draft-sorrento-rsvp-bi-osp-00.txt
1. Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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 made obsolete 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.
2. Abstract
We propose an extension to RSVP-TE for setting up and maintaining
Bi-directional Optical Switched Paths (BOSPs) in optical networks
with symmetric traffic patterns. The requirement for wavelength
continuity for some types of optical networks with no (or partial)
wavelength conversion is also supported. It follows the framework
of MPLS and extends the RSVP-TE to support the signaling for the
provisioning of BOSPs. We introduce a new c-types for bi-directional
LSPs in both Label Request object and Label object. Each LSR (OXC),
upon receiving an RESV message for a BOSP, will allocate a pair of
labels. One label is for the incoming port from the next hop and
the other is for the incoming port from the previous hop. The labels
here include fiber ID, wavelength ID and sub-channel ID (if
applicable). This extension requires a minimum change to the
existing RSVP-TE protocol. It avoids the problem of contention where
two OXCs assign the same wavelength on a uni-directional link for
two different sessions. This contention arises in both [4] and [5].
As a result, no additional mechanism for contention resolution is
needed.
3. Introduction
It is desired to provision bi-directional end-to-end optical paths
in optical networks operated by carriers and CLECs. This is driven
largely by symmetric traffic requirement in the networks. Setting
up two uni-directional paths between two end-points as an equivalent
of a bi-directional path has the following drawbacks:
1. Two uni-directional paths may follow two different physical
(fiber) routes;
2. There is a time gap for setting up two uni-directional paths
between two end-points. This may introduce a contention for
resources. It is possible that we will get a deadlock. It may
have to abort the setup of a bi-directional path because only
one uni-directional path is established.
3. Longer setup latency may be needed.
The overall framework for this document is the MPLS as applied to
optical networks. We take the approach of RSVP-TE for label
distribution.
This subject has been studied in the earlier works of [4] and [5].
In [4], the approach is to introduce a Label object in the Path
message for allocating the label in the direction from the source
to the destination. This deviates from the receiver-initiated
approach of path setup (i.e., initiated by RESV messages) in the
RSVP. In [5], the approach is for RESV messages to allocate two
labels for both incoming and outgoing ports. Both approaches must
handle the potential race condition that two set-up attempts at the
same time may result in a contention for allocating labels. [5]
introduces a mechanism for a pair of OXCs to form master-slave pair
and specifies that only master (which has a higher IP address) can
allocate the label. A similar mechanism involving IP address is also
used in [4] to resolve the contention.
We introduce a new c-type for bi-directional LSP in both Path
messages and Resv messages. When each OXC receives an RESV message,
it allocates two labels, one for the incoming link from the
next OXC and the other for incoming link from the other direction.
The label is referred to the object containing information for fiber,
wavelength and sub-channel (if applicable).
Because each uni-directional link can be considered to be an incoming
link for only one OXC, no OXCs can engage in a contention scenario
where two OXCs assign the same wavelength on a uni-directional link
for two different sessions. This reduces the complexity of the
protocol. Our approach minimizes the change to the original RSVP-TE
protocol.
Another issue is the wavelength continuity requirement for certain
types of optical networks where OXCs provide no (or partial)
function of wavelength conversion. As a result, an optical path from
the source to destination may have to stick to a wavelength in this
type of networks. RSVP-TE need to be extended to support this type
of optical path setup.
We organize the rest of this document as follows. In Section 4,
we define the necessary new c-types for our proposed extension. In
Section 5, we discuss the Path message for pair-wise label request.
In section 6, we discuss the Resv messages for pair-wise label
allocation. We briefly discuss how BOSPs are torn down in section 7.
4. Extensions for Bi-directional OSPs
We define a new C_Type for the label request object defined in [3]
as follows:
Label Request with BOSP
Class=19, c_type = 8 (Bi-directional OSP_Tunnel)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags | L3PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Port # | Maximum Port # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Wavelength # | Maximum Wavelength # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Subchannel # | Maximum Subchannel # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved: This field is reserved. It MUST be set to zero on
transmission and MUST be ignored on receipt.
Flags (8 bits):
01 Bi-directional OSP without wavelength continuity requirement
02 Bi-directional OSP with wavelength continuity requirement
L3PID (16 bits): An identifier of the layer 3 protocol using this
path. Standard Ethertype values are used.
Minimum Port # (16 bits): This field specifies the lower bound of a
a range of port numbers supported on the originating OXC.
Maximum Port # (16 bits): This field specifies the upper bound of a
range of port numbers supported on the originating OXC.
Minimum Wavelength # (16 bits): This field specifies the lower bound
of a range of wavelengths supported on the originating OXC. In the
case of Bi-directional OSP with wavelength continuity requirement,
this field suggests the wavelength that should be used for the data
path from the originating OXC to destination OXC.
Maximum Wavelength # (16 bits): This field specifies the upper bound
of a range of wavelengths supported on the originating OXC. In the
case of Bi-directional OSP with wavelength continuity requirement,
this field suggests the wavelength that should be used for the
reverse data path from the destination OXC to originating OXC.
Minumum Subchannel # (16 bits): This field specifies the lower bound
of a range of subchannel supported within a single wavelength on the
originating OXC.
Maximum Subchannel # (16 bits): This field specifies the upper bound
of a range of subchannel supported within a single wavelength on the
originating OXC.
We also add a new C_Types to the Label objects. The LABEL objects
have the following format:
LABEL class = 16, C_Type = 8
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port ID1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wavelength ID1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-channel ID1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port ID2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wavelength ID2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-channel ID2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5. Operation for Pair-wise Label Request
We list our assumptions below:
a) An ingress OXC is a sender and a receiver of the
SAME traffic class. All optical channel are uni-directional.
b) At each OXC, there is a table containing the information which
spell out how a uni-directional fiber in one direction is paired
to another uni-directional fiber in other direction. This table
also spells out the adjacency of OXCs and how ports are connected
to the neighbors of this OXC. This table will be dynamically
updated.
A Path Message is initiated by one OXC (called the initiating OXC)
and forwarded to the other end (called the responding OXC) of the
bi-directional path. We introduce a new c-type to identify a bi-
directional label request. Upon receiving a Path message, an OXC
will record the bi-directional label request into its Path State
Block (PSB).
6. Operation for Pair-wise Label Reservation
An RESV Message is initiated by the responding OXC for this bi-
directional path. The RESV message will be propagated to the
initiating OXC of this bi-directional path.
+-----+ +-----+ L +-----+
To | | | | <------- | | To
Prev ----| A | L' | B | | C |---- Next
OXC | | --------> | | | | OXC
+-----+ +-----+ +-----+
Fig. 1 OXC B will allocate labels for two incoming
uni-directional links L and L'.
An OXC (in Fig 1, OXC B), upon receiving an RESV message, will
assign labels for two incoming uni-directional links (L and L'),
one going toward the initiating OXC and the other going toward the
responding OXC. (An equally valid scheme is to assign two labels
for both outgoing uni-directional links of an OXC.) The label
allocation is atomic - either both labels are assigned or no label
is assigned. This avoids the potential deadlock.
The adjacent OXC at the next hop (i.e., OXC C Fig 1) need to be
informed about the label allocation for link L. For this purpose,
OXC B will send a special RESV-ERROR Message to OXC C for informing
the allocation. To ensure proper interpretation of this message, a
new error code (Error code 26) is defined. This message is intended
for the adjacent node only and should not be propagated further.
When the adjacent node receives the RESV-ERROR message with error
code 26, it will extract the label assignment. At that point, this
OXC can start to program the switch fabric for this connection.
We show the messages passing at OXC B in Fig 2.
+-----+ +-----+ RESV +-----+
Prev | OXC | |OXC | <------------ |OXC |
-----| A | RESV | B | | C |---Next
OXC | | <-------- | | ------------> | | OXC
+-----+ +-----+ RESV-ERR(26)+-----+
Fig. 2 Messages passing at OXC B. OXC B allocates two labels
for links L and L' at Fig 1.
Because each uni-directional link serves as an incoming link for only
one OXC, it is impossible that two OXCs can engage in a contention
where two OXCs assign the same wavelength on a uni-directional link
for two different sessions. Thus, the contention problem, as
addressed in both [4] and [5], does not arise. We therefore do not
need additional mechanism to resolve the contention. This reduces
the complexity of extension for setting up bi-directional OSP.
The assignment of labels is carried out by the label manager under
the consideration of bandwidth constraint and wavelength constraint.
Under the constraint of wavelength continuity, the label manager
will use the wavelength suggested in the Label Request messages.
The OSP in each direction will use the same wavelength from end to
end.
When no label can be assigned due to resource constraint or other
reasons (such as rejected by policy control), an RESV-Err message
will be sent and propagated toward the responding OXC. That will
trigger the labels allocated to be torn down and cause the session
to fail.
7. Operation for Teardown Messages
An ResvTear message must delete the reserved labels for both
directions (one going forward and the other going backward) and
travels towards all OXCs to the initiating OXC. A PathTear message
travels towards all OXCs to the responding OXC and deletes the path
state, as well as all dependent reservation state, along the way.
A PathTear (ResvTear) message may be conceptualized as a reversed-
sense Path message (Resv message, respectively).
8. Security Considerations
No new security issues are raised in this document. See [1] for a
general discussion of security issues for RSVP.
9. References
[1] Braden, R., Zhang, L., Berson, S., et al, "Resource ReserVation
Protocol -- Version 1 Functional Specification," RFC 2205,
September 1997.
[2] Awduche, D. O., Rekhter, Y., Drake, J., Coltun, R., "Multi-
Protocol Lambda Switching: Combining MPLS Traffic Engineering
Control with Optical Crossconnects," Internet Draft, draft-
awduche-mpls-te-optical-00.txt, October 1999.
[3] Awduche, D. O., Berger, L., Gan, D.-H., Li, T., Swallow, G.,
Srinivasan, V., "Extensions to RSVP for LSP Tunnels," Internet
Draft, draft-ietf-mpls-rsvp-lsp-tunnel-04.txt, September 1999.
[4] Lang, J. P., Mitra, K., Drake, J., "Extensions to RSVP for
optical networing," Internet Draft,
draft-lang-mpls-rsvp-oxc-00.txt, March 2000
[5] Saha, D., Rajagopalan, B., Tang, B., "RSVP Extensions for
Signaling Optical Paths," Internet Draft,
draft-saha-rsvp-optical-signaling-00.txt, March 2000
10. Acknowledgement
The authors would like to thank Frank Barnes for the helpful
discussion and encouragement.
11. Authors' Addresses
Dan Guo James Fu
Sorrento Networks, Inc. Sorrento Networks, Inc.
9990 Mesa Rim 9990 Mesa Rim
San Diego, CA 92121 San Diego, CA 92121
Voice: +1 (858) 450-4964 Voice: +1 (858) 450-4924
Email: dguo@sorrentonet.com Email: jfu@sorrentonet.com
Leah Zhang Raymond Cheung
Sorrento Networks, Inc. Sorrento Networks, Inc.
9990 Mesa Rim 9990 Mesa Rim
San Diego, CA 92121 San Diego, CA 92121
Voice: +1 (858) 450-4977 Voice: +1 (858) 450-4952
Email: leahz@sorrentonet.com Email: rcheung@sorrentonet.com
Guo et al. Internet Draft 6
Internet Draft draft-sorrento-rsvp-bi-osp-00.txt Jan. 2001
| PAFTECH AB 2003-2026 | 2026-04-24 00:06:30 |