[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ID: draft-krishnaswamy-optical-rsvp-extn-00.txt
Hi,
Please post the attached draft on the IETF internet draft directory.
>From Abstract:
We propose an extension to RSVP-TE that would permit setting up optical
channel connections whose paths form a topology that is independent of the
control layer topology.
Thank you,
Murali Krishnaswamy
Photuris Inc.
murali@photuris.com
<<rsvp.txt>>
Internet Draft Murali Krishnaswamy
Leah Zhang
Antonio Rodriguez-Moral
Photuris Inc.
Expires August 2001 22 February 2001
Lightpath Route Extensions to RSVP-TE for
optical channel connection setup
<draft-krishnaswamy-optical-rsvp-extn-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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.
1. Abstract
We propose an extension to RSVP-TE [1][2]that would permit setting up
OCh (optical channel) connections whose paths form a topology that is
independent of the control layer topology. This separation of an OCh
connection path and the associated control layer network may be
necessary for many reasons. First, it may not be possible to provide
a control channel connection to each one of an optical network
element (ONE)'s neighbor - for many reasons explained in Sec. 2. (ONE
as used in this draft includes optical cross-connect (OXC), optical
add-drop multiplexer (OADM) or even optical terminal multiplexer
(OTM). Secondly by providing the means to signal OCh connections
through different multiple control paths, we achieve network
resilience against control channel failure. We propose a new
Krishnaswamy, et al. [Page 1]
I.D. draft-krishnaswamy-optical-rsvp-extn-00.txt
extension to RSVP-TE called Lightpath Route Object (LRO) which is a
list of nodes along OCh connection path. This is carried in the Path
message by RSVP-TE as an Opaque Object for interpretation and use by
the optical nodes. This facilitates setting up OCh connections
between nodes that have no adjacency at the IP layer.
2. Introduction
OCh connections can be setup using a signaling scheme similar to
those proposed in the Generalized MPLS signaling drafts [3][4]. Due
to the multiple influencing parameters, the end-to-end path for OCh
connections is always predetermined and signaled as ERO using RSVP-
TE. An implicit (and required) assumption in such cases is that, the
OCh path aligns with the control path. This OCh and control path
association is necessary as RSVP-TE requires IP adjacency. Further
the proposed OSPF extensions to support MPlambdaS [5] and the opaque
TE extensions in general [6], advertise only those TE parameters
(both control and OCh) that are specific to that control channel
(link). (Note: Even if an OCh connection that doesn't belong to a
particular link is advertised over that link, still there is no way
of signaling an OCh path that is different from the control path
(ERO).
Control Channel
++++++++++++++ +-------+ ++++++++++++++
+ -------------| A |------------- +
+ | | | OCh-Ring-1 | +
+ | --------- | | --------- | +
+ | | +-------+ OCh-Ring| | +
+ | | -2 | | +
+-------+ +-------+
| D |-------------------------| B |
| | | |
+-------+ +-------+
+ | | +
+ | | +
+ | +-------+ | +
+ |------------| C |------------| +
+++++++++++++++| |+++++++++++++++
+-------+
Fig. 1 - Multiple Rings.
OCh-Ring 1 - A-B-C-D
OCh-Ring 2 - A-B-D (No control channel between B-D)
This dependency makes it impossible to set up OCh connections between
two nodes if they have no adjacency at the IP layer - ie. if there is
no control channel between them (B-D in Fig.1). Hence a network
Krishnaswamy, et al. [Page 2]
I.D. draft-krishnaswamy-optical-rsvp-extn-00.txt
operator can't configure and offer ring configurations similar to
OCh-Ring-2.
Thus this control/OCh layers topology association puts limitations in
the deployment and features that can be offered by a network
operator.
Some of the reasons for not providing control channel between
adjacent nodes are:
o Since the control channels are terminated in each node,
optics/hardware architecture may limit the total number of con-
trol channels in an optical node. This may be especially true in
a low cost access/metro WDM system or in highly meshed network.
o Where an out-of-fiber separate control channel (eg. ethernet) is
deployed, it is difficult to colocate the controls channel along
all of the optical paths.
A more compelling reason for LRO is the case of optical ring networks
where a network operator would typically prefer to setup "short side"
connections even in the event of the control channel failure along
this path (Fig. 2). As the control channel uses a separate wave-
length, for eg. its transmitter/receiver could fail, while all the
other wavelengths (that carry user data) remain unaffected. One less
obvious disadvantage of a long side connection is that it could
increase the blocking probability for future wavelength allocations.
+-------+ Control Channel Failure
+++++++++++++++| A |+++++++++ X X X
+ ----------| |---------- X
+ | +-------+ OCh | X
+ | | +
+ | | +
+-------+ +-------+
| D | | B |
| | | |
+-------+ +-------+
+ | | +
+ | | +
+ | +-------+ | +
+ ----------| C |---------- +
+++++++++++++++| |+++++++++++++++
+-------+
Fig. 2 - Control Channel Failure between A-B
Krishnaswamy, et al. [Page 3]
I.D. draft-krishnaswamy-optical-rsvp-extn-00.txt
When the control channel between A and B fails, it is not possible to
setup short side (A-B) OCh connections between A and B using RSVP-TE
even though the data channels between them remain unaffected. With
LRO extensions we would be able to signal and setup the short side A-
B OCh connection (by specifying LRO as A-B) while letting the control
message go through the longer path A-D-C-B (or B-C-D-A).
Note: Link Management Protocol [7] proposes protection control chan-
nels for maintaining link connectivity. The protection control chan-
nel takes over when the primary one fails. However such proposals
may not be feasible in many systems for architectural and economic
reasons.
3. Lightpath Route Object (LRO)
Owing to the above reasons we propose an extension to RSVP-TE called
Lightpath Route Object and this is a list of the nodes in the OCh
connection path. LRO is carried in the Path message and is treated
as an Opaque Object by RSVP-TE. It is up to the applications on the
nodes to use the path information in LRO to set up the OCh connec-
tions. RSVP-TE (control path) itself follows the ERO path only.
The lightpath routes are specified by the LIGHTPATH_ROUTE object
(LRO).
3.1 Path Message
The format of the Path message is as follows:
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <LIGHTPATH_ROUTE> ]
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <SESSION_ATTRIBUTE> ]
[ <POLICY_DATA> ... ]
<sender descriptor>
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
The relative placement of LIGHTPATH_ROUTE object is simply a
Krishnaswamy, et al. [Page 4]
I.D. draft-krishnaswamy-optical-rsvp-extn-00.txt
recommendation. The ordering of the objects is not important, so an
implementation MUST be prepared to accept objects in any order.
We define a new Lightpath route class = 22 (check), c_type = 1.
3.2 LIGHTPATH_ROUTE Format
LIGHTPATH_ROUTE has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The contents of an LIGHTPATH_ROUTE object are a series of variable-
length data items called subobjects. Each subobject has the form:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+
|L| Type | Length | (Subobject contents) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+
L
The L bit is reserved.
Type
The Type indicates the type of contents of the subobject.
Currently defined values are:
0 Reserved
1 IPv4 prefix
2 IPv6 prefix
Length
The Length contains the total length of the subobject in bytes,
including the L, Type and Length fields. The Length MUST be at
least 4, and MUST be a multiple of 4.
Krishnaswamy, et al. [Page 5]
I.D. draft-krishnaswamy-optical-rsvp-extn-00.txt
Two Subobjects are defined - for IPv4 and IPv6.
Subobject 1: IPv4
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | IPv4 address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (continued) | Resvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L
The L bit is reserved.
Type
0x01 IPv4 address
Length
The Length contains the total length of the subobject in
bytes, including the Type and Length fields. The Length
is always 8.
IPv4 address
An IPv4 address (of the optical node).
Padding
Zero on transmission. Ignored on receipt.
Subobject 2: IPv6
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | IPv6 address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) | Resvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Krishnaswamy, et al. [Page 6]
I.D. draft-krishnaswamy-optical-rsvp-extn-00.txt
L
The L bit is reserved.
Type
0x02 IPv6 address
Length
The Length contains the total length of the subobject in
bytes, including the Type and Length fields. The Length
is always 20.
IPv6 address
An IPv6 address (of the optical node).
Padding
Zero on transmission. Ignored on receipt.
4. LRO and ERO
Though LRO is an Opaque object as far as RSVP-TE is concerned, a few
guidelines are provided regarding its usage and its co-existence with
ERO.
o First of all to help implementation LRO is defined such that its
format is similar to ERO.
o When the RSVP-TE message has no LRO, then the optical nodes must
use the path specified in the ERO for the OCh connection.
o When the RSVP-TE message carries LRO, then the optical nodes
must use the path specified in the LRO for the OCh connection.
o The LRO nodes must be a sub-set of the ERO nodes.
o The source and destination nodes of the LRO and ERO must be the
same.
o On an implementation note a source node must reject a connection
request if the above two requirements are not satisfied.
5. Label operation in the presence of LRO
Krishnaswamy, et al. [Page 7]
I.D. draft-krishnaswamy-optical-rsvp-extn-00.txt
In switched optical networks the labels carried in the Resv message
are generally encoded to represent the WDM channels or lambdas that
have been selected by the downstream neighbors. In cases where the
LRO is not the same as ERO (normally this should be the case as oth-
erwise no LRO is required), the label allocation and usage is
slightly different.
When LRO is specified, those intermediate nodes which are not a part
of LRO (non-LRO nodes) must generate "dummy" or some "pre-assigned"
labels that are recognized by LRO nodes. (A node determines if it is
a LRO or non-LRO node by looking in to the PSB). Only the LRO nodes
generate valid labels useful for setting up OCh connections. If a
LRO member node upon receiving the Resv message, finds that the top
label is a dummy one, it must then ignore that and look down in to
the stack till it finds a valid label. (This label will obviously
correspond to that of its predecessor LRO node). It is this label
that a LRO node must use for setting up OCh connections.
Note: This draft doesn't modify the RSVP-TE behavior.
6. Security Considerations
This draft doesn't raise any security considerations.
7. References
[1] Braden, R. et al., "Resource ReSerVation Protocol (RSVP) - Version
1, Functional Specification", RFC 2205, September 1997.
[2] Awduche, D. et al., "RSVP-TE: Extensions to RSVP for LSP Tunnels",
Internet Draft, draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, August
2000.
[3] Ashwood-Smith, P. et. al., "Generalised MPLS - Signaling Func-
tional Description", Internet Draft, draft-ietf-mpls-generalised-
signaling -00.txt, October 2000.
[4] Ashwood-Smith, P. et. al., "Generalised MPLS Signaling - RSVP-TE
Extensions", Internet Draft, draft-ietf-mpls-generalised-rsvp-te
-00.txt, November 2000.
[5] Kompella, K. et. al., "OSPF Extensions in Support of MPL(ambda)S",
Internet Draft, draft-kompella-ospf-ompls-extensions-00.txt, July
2000.
Krishnaswamy, et al. [Page 8]
I.D. draft-krishnaswamy-optical-rsvp-extn-00.txt
[6] Katz, D. et. al., "Traffic Engineering Extensions to OSPF", Inter-
net Draft, draft-katz-yeung-ospf-traffic-03.txt, September 2000.
[7] Lang, J. et. al., "Link Management Protocol [LMP]", Internet
Draft, draft-lang-mpls-lmp-02.txt, July 2000.
8. Authors' Addresses
Murali Krishnaswamy, Leah Zhang, Antonio Rodriguez-Moral
Photuris Inc.
20 Corporate Place South
Piscataway NJ 08854
Tel: +1 (732) 465 1000 x1220, x1252, x1343
Fax: +1 (732) 465 1010
E-mail: murali, lzhang, arodmor@photuris.com
Krishnaswamy, et al. [Page 9]