Internet DRAFT - draft-long-gmpls-obs
draft-long-gmpls-obs
Internet Engineering Task Force Keping Long
Internet Draft Zhang Yi
Expires: May 2006 Yang Xin
Xiaolong Yang
Huiqing Liu
Special Research Centre for Optical Internet and
Wireless Information Networks (COIWIN)
Chongqing University of Post & Telecommunications
November 2005
Generalized MPLS (GMPLS) architecture's
extensions for Optical Burst Switch network
draft-long-gmpls-obs-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.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
The Generalized MPLS[RFC 3031] suite of protocols has been defined to
control different switching technologies, such as TDM, Optical
Circuit Switching, and even Optical Fibre Switching. However, Optical
Burst Switching(OBS)[Qiao] is a promising optical switching
technology, which is expected to be deployed in optical network in
the very near future. Therefore, this document focuses mainly on how
to extend the architecture of Generalized MPLS (GMPLS)[RFC 3945] to
support Optical Burst Switching. Herein, the extensions consist in
the following issues, i.e., signaling, routing and link management.
What more, the extended GMPLS architecture will be much more scalable
Long,Zhang,Yang,Yang,Liu Standards Track [Page 1]
------------------------------------------------------------------------
Internet Draft MPLS's extensions for OBS November 2005
than before. Note that the extensions are not limited a certain OBS
signaling type, such as Just-In-Time or Just-Enough-Time, Wavelength-
Routed OBS or traditional OBS.
Conventions
The keywords "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 [RFC 2119].
Long,Zhang,Yang,Yang,Liu Standards Track [Page 2]
------------------------------------------------------------------------
Internet Draft draft-long-gmpls-obs-00.txt November 2005
Table of Contents
1. Introduction.....................................................4
1.1 Terminology.................................................4
2. GMPLS Extensions for OBS -Overview...............................4
2.1 New type of Switching and Forwarding Hierarchy..............5
3. Routing and Addressing Model.....................................5
3.1 Addressing of BSC in hybrid control network.................6
3.2 Unnumbered Links............................................6
3.3 Link Bundling...............................................7
4. GMPLS Signaling Extensions for OBS...............................7
4.1 Label-Switched OBS Control Packet...........................7
4.2 Signaling Message's Extensions..............................8
4.3 LSP in OBS networks.........................................8
4.4 Explicit route consideration................................9
4.5 Link protection and re-routing..............................9
5. Link Management..................................................9
5.1 Channel Group and Manage...................................10
5.2 OBS DCG's Bundling.........................................10
5.3 Link connectivity verifying................................10
5.4 Fault Location and Notification............................11
6. Security Considerations.........................................11
7. Acknowledgements................................................12
8. References......................................................12
9. AUTHORS'ADDRESSES...............................................13
10.IPR NOTICE......................................................14
11.FULL COPYRIGHT STATEMENT........................................14
Long,Zhang,Yang,Yang,Liu Standards Track [Page 3]
------------------------------------------------------------------------
Internet Draft draft-long-gmpls-obs-00.txt November 2005
1. Introduction
MPLS is generalized to enable many switching interfaces (such as
Time-Division Multiplex Switching Capacity interface, Lambda
Switching Capacity interface and Fibre Switching Capacity interface,
and etc.), and its generalized version (GMPLS) has be regarded as
the most popular control plane protocol suite. Among several optical
switching paradigms, Optical Burst Switching (OBS) is the most
promising ones, which is able to exploit the terabit bandwidth in
optical networks while effectively circumventing the problem of
optical buffering and complex optical logic processing. Up to now, it
is hopeful for OBS to be used to the commercial optical networks in
very near future. Hence, the extension of GMPLS to OBS, i.e. enabling
OBS capacity interface, is one more interesting topics in optical
internetworking.
In the ingress node, packets(cell, frame) are collected into an
optical burst before being sent into the OBS network. In essential,
the burst assembly is the process of higher-layer flow aggregation,
which purpose is to improve the efficiency of the optical processing
and simplify the flow management in intermediate optical nodes. As
soon as a data burst(DB) is ready, its corresponding Burst Header
Packet(BHP) will be generated and sent into a separate control
wavelength, i.e. Optical Burst Switching Control Channel(CC). In this
way, enough resources are reserved, and the optical switching fabric
(e.g.OXC) are deployed for the corresponding DB¡¯s transparent
transmission in optical domain. Some offset-time later, DB will be
sent into Optical Burst Switching Data Channel(DC).
1.1. Terminology
Frequently used terms are as follows:
MPLS - Mutiprotocol Label Switching
LSP - label switched path
LDP - Label Distribution Protocol
OBS - optical burst switch
LSR - Label Switching Router
2. GMPLS Extensions for OBS - Overview
In the enhanced GMPLS architecture, the control plane remains
departed from data plane. The architecture of OBS network is also
divided into two parts, i.e., one for transporting BHP, and the other
for transporting DB. The BHP has to deploy the switching fabric of
OBS node to enable its related DB to be switched without o/e/o
conversion. In order to BHP's switching control can be be cooperative
with DB's all-optical transmission, the data channel and control
channel are bundled together logically, and there will be at least a
Long,Zhang,Yang,Yang,Liu Standards Track [Page 4]
------------------------------------------------------------------------
Internet Draft draft-long-gmpls-obs-00.txt November 2005
dedicated wavelength for BHP between two OBS nodes to transmit BHP.
When a OBS Label Switching Path(LSP) is requested, two related
sub-LSPs are successively established for BHP and DB respectively.
At each OBS node, the output wavelength or port for each Data Burst
is decided locally and temporary the scheduling time when a BHP is
processed. Link Management Protocol [LMP] is also extended for OBS
local link management. In OBS network, the BHP has to be disposed by
each OXC node, and then the deployed OXC node will be transparent to
the corresponding DB which means the DB will go directly to the
outgoing wavelength without o/e/o conversion. In this situation, it
will be difficult to verify a link fault in transparent OXC node. On
the other hand, the control channel must has a mapping relationship
with the data channel. This kind of local mapping must be done by
LMP.
2.1. New type of Switching and Forwarding Hierarchy
The GMPLS architecture defined by [RFC3945] supports not only the
LSRs whose forwarding information carried by packet or cell, but the
ones whose forwarding information is decided by time slot,
wavelength, or physical ports which are called, more precisely the
interfaces of the LSRs, individually the Packet Switching Capacity
(PSC) interfaces, Layer-2 Switching Capable (L2SC) interfaces, Time-
Division Multiplex Capable (TDM) interfaces, Lambda Switching Capable
(LSC) interfaces, Fiber-Switching Capable (FSC) interfaces.
A new kind of interface SHOULD be defined to support OBS LSP. Beause
all the switching information is carried by BHP in control channel,
the interfaces that can transmit BHP from optical signal into
electric signal and then deal with it will be called Burst Switching
Capacity (BSC) interfaces.
BSC interfaces recognize BHP boundaries, read content of the header
and transmit the packet to the control unit, finally forward the BHP
to the appointed outgoing control channel. An example of such an
interface is the one on Fast Optical Cross-connect with OBS control
unit that is used to deal with BHP. If OBS CC is wavelength based,
then BSC interfaces will transmit BHP from electrical to optical or
vice versa, and BHP will be sent to the OBS control unit to reserve
wavelength resource for its corresponding DB and to deploy the Cross-
connect unit if data channel is scheduled successfully. After reading
DB message, BHP will be modified in control unit: the offset time
will be re-calculated and the DB wavelength will be changed to the
scheduled one. In the end, BHP will be sent into Control Channel
again through BSC. If in the egress node of OBS network, the BHP will
be dropped by BSC the time recognized, because all the DB will be
disassembled.
3. Routing and Addressing Model
The enhanced GMPLS architecture in this document is still based on IP
routing and addressing models. The routing and addressing model is
based on the OBS Control Channel. If not all the OBS switching
Long,Zhang,Yang,Yang,Liu Standards Track [Page 5]
------------------------------------------------------------------------
Internet Draft draft-long-gmpls-obs-00.txt November 2005
fabrics have the ability of wavelength conversion, the routing has to
consider wavelength-continuity constraint too. The control channel
and data channel are both belonging to the data plane. In traditional
electrical network, each PSC interface or router is identified by an
IP address uniquely locally or all around the Internet.
In OBS network, only OBS Control Channel needs routing and
addressing. Hence, every interface of Control Channel SHOULD be
identified uniquely, usually by IP address in local network or in the
whole internet. Routing or address has nothing to do with OBS Data
Channel, only after data channel schedule with routing information of
BHP at control unit of each switching node, can DB's outgoing data
channel be decided locally, which makes it no need to identify data
channel interface with unique IP address in the network. Hence, the
data interface can be identified with <node ID, local link port ID,
local wavelength ID>. the "node ID" CAN be IP address or unnumbered,
while "local link port ID" and "local wavelength ID" are indices to
local node, and MUST be known by the destination node of this link.
It is Link Management Protocol that maps local link port or
wavelength ID to the ones of the node at the other side of link.
The OBS network can be envisioned as two coupled overlay networks: a
pure optical network transferring data bursts, and a hybrid control
network transferring burst header packets (BHPs). All the routing and
addressing information is about control network.
3.1. Addressing of BSC in hybrid control network
IPv4 or IPv6 addresses are still used to identify the BSC interfaces
of OBS network. However it is not requested to share address space
with the internet address space. It depends on the relationship
between control network and the internet. In overlay mode, the OBS
router and control network is identified with private IP address. In
integrated mode, the IP address space is the same as the internet.
Finally, the pure optical network interfaces transferring data burst
maybe "unnumbered" and "local identified" in case of not having IP
address distributed.
3.2. Unnumbered Links
Unnumbered links (or interfaces) are extended to support both OBS
control channels and data channels in the two capacities that are
defined in [RFC3945]: specify unnumbered links and carry unnumbered
links information in IGP TE.
A. the links (or interfaces) are divided into two kinds: control
channel and data channel, so the identifiers that specify
unnumbered links are extended to identify the channel is for
control or data.
B. When carry (TE) information about unnumbered link of OBS, the new
sub_TLVs, that defined for IS reachability TLV in IS-IS-TE or for
the TE LSA in OSPF-TE, is also extended to indicate whether it is
Long,Zhang,Yang,Yang,Liu Standards Track [Page 6]
------------------------------------------------------------------------
Internet Draft draft-long-gmpls-obs-00.txt November 2005
for control channel or data channel.
3.3. Link Bundling
The concept of Link Bundling is employed in certain network that has
GMPLS control plane is defined by [BUNDLE]. In traditional OBS
network without Link Bundling, considering both Link Manage Protocol
and link state routing protocols, they have to advertise every
wavelength with control channel or data channel identifier for
resource discovery and dynamic route computation.
In this network, LSPs between two LSRs can be bundled into Bundling
however this bundling is in different form from the traditional ones.
Because the stream of BHP has very low traffic, usually there are
many streams of BHPs sharing physical channel with others. However,
each DB stream requests as wide bandwidth as a data channel, and many
DB will do data channel schedule. OBS data channels sharing some
appropriate properties being bundled together can meet the request.
4. GMPLS Signaling Extensions for OBS
The GMPLS signaling extends some functions and modules of the RSVP-
TE[RFC 3209] and CR-LDP[RFC 3212] signaling. The core GMPLS signaling
specification are available in four parts: 1. A signaling functional
description [RFC3471]. 2. CR-LDP extensions [RFC3472]. 3. RSVP-TE
extensions [RFC3473]. 4. GMPLS architecture [RFC3945].
In order to support OBS, The GMPLS signaling need some new building
blocks: 1. Some new traffic parameter TLVs for generic request
messages. 2. OBS switching support. 3. New approach for Path's
setting up. 4. Signaling extensions for explicit route in OBS
networks. 5. Protection and restoration's extensions.
These building blocks will be described in more details in the
following.
In OBS networks, traffic packet (DB) and its control header (BHP) are
transported in control channel and data channel separately, control
header is sent earlier than its traffic packet, it reserves bandwidth
along the forwarding path in order to achieve the all-optical
transmission of its DB. Contrast to general packet-switch which is
defined in [architecture], the primary difference is the separate
transmission of DB and BHP, this need some enhancements and
modifications of generic GMPLS signalling which is described in
[architecture]. GMPLS signalling must sets up label-switched path or
support label-swapped for BHP, and it should provide the constrained
virtual path (not detailed path, maybe a channel range) for DB if
necessary.
4.1. Label-Switched OBS Control Packet
In traditional OBS networks, control packet (BHP) is treated as an IP
packet, and its processing and forwarding are IP-based. But in GMPLS-
Long,Zhang,Yang,Yang,Liu Standards Track [Page 7]
------------------------------------------------------------------------
Internet Draft draft-long-gmpls-obs-00.txt November 2005
based network, packet's processing and forwarding are label-based in
general conditions. In order to support OBS, there need some
enhancements of GMPLS:
1) OBS control packet (BHP) is treated as generic packet and packet-
switched according to the processes which are defined in
[architecture].
2) The traffic packet (DB) is defined as a special kind of packet,
which is switched and forwarded like it in classic OBS networks:
DB's route and resources are controlled by its BHP, its forwarding
is all-optical.
OBS control packet's (BHP) destination address is replaced by a
label.This kind label is a GMPLS generalized label, it is distributed
by the specific signaling protocol (CR-LDP or RSVP-TE). And the
processing and forwarding of BHP is achieved by various operations of
this label.
4.2. Signaling Message's Extensions
In order to support Optical Burst Switching, the defined signaling
messages in GMPLS signaling protocols must be enhanced by adding some
TLVs to signaling messages. On account of the particular transmission
approaches of OBS, Both DB's and BHP's traffic requirements must be
considered together during path computing and path establish. So it
needs some new TLVs to take the traffic requirements information
about BHP and DB in GMPLS' signaling messages. For example, there
need a TLV to take the traffic parameters of DB in label request
messages to inform nodes about requirements of DB. The detailed
addition of TLVs is out of this document's discussion range.
4.3. LSP in OBS networks
In GMPLS networks with out-of-band signaling, channels are sorted
into two classes: GMPLS control channel and GMPLS data channel. GMPLS
control information packets including routing, signaling and link
management packets are transported in GMPLS control channel, these
information packets' forwarding are IP-based. And traffic packets (DB
and BHP) are transported in GMPLS data channel, these packets are
label-swapped typically. But there are something unlike general GMPLS
network owe to some particular characteristic of OBS networks.
There are two kinds of packet in OBS networks: Data Burst (DB) and
Burst Header Packet (BHP). The path of BHP is a typical
label-switched-path (LSP), the LSP's establish processing is as same
as it in MPLS or GMPLS networks. The detailed path of DB is not
designated in advance, they are determined by the nodes in its route
according to the online state of network resources, and DB's path can
be setup as a virtual path and constrained in some channel ranges if
necessary.
Long,Zhang,Yang,Yang,Liu Standards Track [Page 8]
------------------------------------------------------------------------
Internet Draft draft-long-gmpls-obs-00.txt November 2005
4.4. Explicit route consideration
When computing and set up an explicit-route path, all nodes in the
computed-route must satisfy the requirements of BHPs and DBs
together, the LSP of BHP can be set up only in this condition.
Otherwise, the request of this BHP LSP will be refused. During the
signaling process,signaling messages must inform each node with
these requirements completely and timely. The detailed processing can
be found in corresponding documents.
4.5. Link protection and re-routing
The primary ideal of OBS is: traffic packet (DB) and its control
header (BHP) are transported in control channel and data channel
separately. So toward each traffic in OBS networks, it has two paths
under general conditions: a control path (BHP LSP) and a data path
(DB path). In OBS networks, link protection and re-routing must
consider both control path and data path, if there is a fault in one
of these two paths, the protection and rerouting operations must
recovery these two paths together. In the case of fault in BHP LSP,
some DB packets may be arrival at next node earlier than its BHP
because of BHP LSP's interrupt, these DB will be discarded. If there
is a failure in DB LSP, some DB packets may be dropped owing to the
failure, their BHP will be also discarded because their corresponding
DB are not existing.
5. GMPLS LMP Extensions for OBS
OBS networks consists of OXC, and Dense Wavelength Division Link. The
OXC has a control unit which has a control plane and BHP delivering
fabric. The control plane runs Generalized MPLS to dynamically
administrate OBS data links and distribute routing and signaling
messages. The BHP delivering fabric deals with BHP to reserve
bandwidth for the corresponding DB and modifies the contents of BHP,
such as offset time, outgoing wavelength, Time To Live, etc. The data
links between two OXCs is grouped into two kinds of channel: OBS
control channel and OBS data channel.
OBS control channel and OBS data channel between two adjacent nodes
are not required to use the same physical medium. For example, an OBS
control channel may transport BHP in electric other than optical.
While the corresponding Data Burst runs transparently in optical
link. For controllable purposes, LMP should be extended to support
both OBS control channel and OBS data channel.
Since the data link is divided into two types, most of the functions
in LMP must be developed, both in terms of link provisioning and
fault management. TE links in OBS network consist of OBS control
channel, and these TE links have corresponding OBS data channels. All
the relationships between them and properties of those two kinds of
links are managed by LMP.
Long,Zhang,Yang,Yang,Liu Standards Track [Page 9]
------------------------------------------------------------------------
Internet Draft draft-long-gmpls-obs-00.txt November 2005
5.1. Channel Group and Management
The first extended function of LMP is the local channel management.
There are three kinds of channels in GMPLS-based OBS network, control
plane channel, control network channel, and pure optical data
channel. An LSP in OBS is made up of control channel and data
channel, the data channel is mapped to the control channel and
related with a group of data channels which have the same next hop.
There might be hundreds or thousands of channels between a pair of
LSR, and control plane channel may be completely departed with data
plane channel, and Considering scalability and facility of GMPLS-
based OBS, the channels in data plane which is OBS network are
grouped into Control Channel Group and Data Channel Group. All the
channels that transport BHP belong to the CCG, and is also departed
with DCG which transport Data Burst transparently.
In the initialization state of LMP, the active bi-directional control
channel which is used to do parameter negotiation changes control
plane information including LMP messages to realize resource
discovery and neighbor discovery.
5.2. OBS DCG's Bundling
All the data channels in use are divided into many data channel group
according to the mapping BHP LSP. The interfaces of a DCG begin and
end on the same pair of LSRs, and they share some common
characteristics, such as data channel schedule algorithm. So the DCG
can be bundled into a bundling for better scalability of TE traffic.
Link Property Correlation is also extended in LMP to correlate BHP
LSPs with a DCG's bundling dynamically. The relationship between them
can be added, deleted or changed by LinkSummary messages.
For example, between LSR A and B there exists some BHP LSPs mapping a
DCG bundling D1. D1 has M component data channels. When a new BHP LSP
is requested to pass A and B, and this LSP can share the same
property with those LSPs at this span, the data channel of this BHP
LSP can be bundled into this bundling with LinkSummary series
messages. Similarly, when a BHP LSP is claimed to be dead, the
mapping data bundling should be modified to delete one data channel
with LinkSummary messages. The bundling will be dead when the last
BHP LSP which is mapping this bundling is claimed to be canceled.
By manage the data channel bundling dynamically can make the OBS
network routing and signaling more scalable, and increase the link
usage, and meet the character of control channel depart from data
channel in OBS network best.
5.3. Link connectivity verifying
This extended function is mainly used to discover neighbor and link
resource exchange after the initialization of OBS network. This
Long,Zhang,Yang,Yang,Liu Standards Track [Page 10]
------------------------------------------------------------------------
Internet Draft draft-long-gmpls-obs-00.txt November 2005
function will do link connectivity verifying and the interface id
exchange of control channel, data channel, and bundling.
It is very important for OBS network. Without the conform of local
and remote interface id of channel or bundling, the information in
BHP will not be explained correctly at each hop, the resource maybe
reserved wrong.
The data channel is X-transparent for DB, so every fiber must have at
least one OBS control channel, by which fiber interface id can be
exchanged, which means at least one wavelength interface can perform
o/e/o convention. And verify transport mechanism only do with OBS
control channel.
Since BHP defines the wavelength in which its DB, and LSR can only
deploy the OXC with the information, there must be a set of coding
criterion indicating each wavelength in one fiber.
5.4. Fault Location and Notification
In this section, the fault location and notification is still an
optional procedure and extended from the part of LMP describing how
data channel failure in OBS is founded.
In the fault detection of OBS network, control channel can be
detected in layer3, but the data channel fault detection can only be
handled in optical layer with some techniques for monitoring optical
signals.
In fault location procedure, there is no change in control channel
location from traditional, while in data channel location, test
message can't be sent downstream. The LSR, which find Loss of Light
or something wrong in data channel, will send notification to
upstream LSR, and the upstream LSR will have to detect its optical
signal from upstream, until the one who find all the upstream signal
is ok can sure that the fault is between itself and the downstream
LSR who notifies him.
6. Security Considerations
In this enhanced GMPLS architecture, there is a control plane for
multiple technologies and types of network elements especially for
OBS, and there is data plane for transporting OBS DB and BHP, in
which still have OBS control channels and OBS data channels. The
security mechanisms for control plane is described in [architecture].
In data plane, BHP is transported though OBS control channel, and
swapped at each node to reserve optical wavelength resources for its
corresponding DB. And the DB will runs transparently in the reserved
wavelength. Hence, GMPLS security MUST extend mechanisms that prevent
or minimize the risk of attackers being able to modify and/or copy
OBS BHP packet. The risks depend on the realization and physical
characteristics of OBS control channel, as well as the level of trust
Long,Zhang,Yang,Yang,Liu Standards Track [Page 11]
------------------------------------------------------------------------
Internet Draft draft-long-gmpls-obs-00.txt November 2005
to the BHP at each node.
The OBS control channel should share the same mechanisms to provide
authentication and confidentiality as the control plane has. In case
of transporting OBS control messages in IP layers, the IPsec suite of
protocols (see [RFC 2402], [RFC 2406], and [RFC 2409])may be used.
In case of OBS control messages over optical directly, some advanced
Encryption methods can be used to provide security.
After all, the authorization of OBS should be executed in the OBS
control channel, starting from ingress and ending in egress, and it
can cooperate with control channel or not.
7. Acknowledgements
This research is funded by the National High Technology Research and
Development Program of China (863 Program).
The authors are grateful to other colleagues and post-graduated
students for their work and useful suggestions.
8. References
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997.
[RFC 3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[OBS] Chuming Qiao and Mungsik Yoo,Optical Burst Switching (OBS)
¨CA new paradigm for an optical Internet, J. High Speed
Networks, vol. 8, no. 1, 1999.
[RFC 3945] E. Mannie, Ed."Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC 3945, October 2004.
[LMP] Lang, J., Ed., "Link Management Protocol (LMP)", Work in
Progress.
[BUNDLE] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
in MPLS Traffic Engineering", Work in Progress.
[RFC 3209] 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.
[RFC 3212] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu,
L.,Doolan, P., Worster, T., Feldman, N., Fredette, A.,
Girish, M.,Gray, E., Heinanen, J., Kilty, T. and A. Malis,
"Constraint-based LSP Setup Using LDP", RFC 3212, January
2002.
Long,Zhang,Yang,Yang,Liu Standards Track [Page 12]
------------------------------------------------------------------------
Internet Draft draft-long-gmpls-obs-00.txt November 2005
[RFC 3471] L. Berger,"Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC3471,
January 2003.
[RFC 3472] P. Ashwood-Smith, L. Berger, "Generalized Multi-Protocol
Label Switching (GMPLS) Signaling Constraint-based Routed
Label Distribution Protocol (CR-LDP) Extensions",
RFC 3472, January 2003.
[RFC 3473] L. Berger, "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC 2402] S. Kent, R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.
[RFC 2406] S. Kent, R.Atkinson, "IP Encapsulating Security Payload
(ESP), RFC 2406, November 1998.
[RFC 2409] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)"
RFC 2409, November 1998.
9. AUTHORS' ADDRESSES
Keping Long
Special Research Centre for Optical Internet & Wireless Information
Networks (COIWIN), Chongqing University of Post & Telecommunications
Chongqing, 400065 P.R. China
University of Electronic Science and Technology of China
Phone: +86 23 6246 0218
Fax: +86 23 6246 0220
E-Mail: Longkp@cqupt.edu.cn
Zhang Yi
Special Research Centre for Optical Internet & Wireless Information
Networks (COIWIN), Chongqing University of Post & Telecommunications
Chongqing, 400065 P.R. China
Phone: +86 23 6246 0223
Fax: +86 23 6246 0220
E-Mail: zhangyi.ben@gmail.com
Yang Xin
Special Research Centre for Optical Internet & Wireless Information
Networks (COIWIN), Chongqing University of Post & Telecommunications
Chongqing, 400065 P.R. China
Phone: +86 23 6246 0223
Fax: +86 23 6246 0220
E-Mail: yangxin99340122@tom.com
Xiaolong Yang
Special Research Centre for Optical Internet & Wireless Information
Networks (COIWIN), Chongqing University of Post & Telecommunications
University of Electronic Science and Technology of China
Long,Zhang,Yang,Yang,Liu Standards Track [Page 13]
------------------------------------------------------------------------
Internet Draft draft-long-gmpls-obs-00.txt November 2005
Chongqing, 400065 P.R. China
Phone: +86 23 6246 0223
Fax: +86 23 6246 0220
E-Mail: yangxl@cqupt.edu.cn
Huiqing Liu
Special Research Centre for Optical Internet & Wireless Information
Networks (COIWIN), Chongqing University of Post & Telecommunications
Chongqing, 400065 P.R. China
Phone: +86 23 6246 0223
Fax: +86 23 6246 0220
E-Mail: liuhq@cqupt.edu.cn
10. IPR NOTICE
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.
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.
11. FULL COPYRIGHT STATEMENT
Copyright (C) The Internet Society (2005). 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 translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
Long,Zhang,Yang,Yang,Liu Standards Track [Page 14]
------------------------------------------------------------------------
Internet Draft draft-long-gmpls-obs-00.txt November 2005
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
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.
Long,Zhang,Yang,Yang,Liu Standards Track [Page 15]
------------------------------------------------------------------------
Internet Draft draft-long-gmpls-obs-00.txt November 2005
