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 . 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