Internet Draft Dan Guo, Jibin Zhan, draft-guo-optical-aps-01.txt Wenjing Chu, Hui Zhang Nov. 2001 (Turin Networks) Dimitri Papadimitriou, Stefan Ansorge (Alcatel) Nasir Ghani, James Fu, Zhensheng Zhang (Sorrento Networks) Dimitrios Pendarakis (Tellium) Expiration Date: May 2002 Sudheer Dharanikota (Nayna Networks) Optical Automatic Protection Switching Protocol (O-APS) 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 describe an Optical Automatic Protection Switching protocol (O-APS) for optical rings. Specifically, the O-APS protocol is an IP-based lightweight protocol which exploits the characteristics of rings and initially supports the optical ring protection on the Optical Channel (OCh) level. The O-APS protocol can also be used for mesh networks, when we view two diverse lightpaths for 1+1 or 1:1 path protection as a logical Optical Channel Dedicated Protection Ring. Functionally the O-APS protocol can be viewed as an optical version of the ubiquitous SONET/SDH APS (Automatic Protection Switching) protocol using K1/K2 bytes. The O-APS protocol performs only protection signaling, independent of fault detection and lightpath provisioning mechanisms. The operational model for O-APS is made compatible with SONET/SDH APS protocol, due to the wide-spread adoption of SONET/SDH APS in many operators' networks. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. Internet Draft D. Guo et al, draft-guo-optical-aps-01.txt [Page 1] 3. Introduction With rapid development of optical add-drop multiplexer (O-ADM) and optical cross-connect (OXC) technologies, optical ring networks emerge as a natural migration choice for operators with existing SONET/SDH networks. Optical rings are of importance due to the large installed base of fiber rings and the extensive OAM&P experience on SONET/SDH rings. In [GHANI], we have provided a generic architectural framework for optical rings. One important feature for dynamic optical rings is their ability to provide fast protection and restoration functionality. Various optical ring protection schemes have been specified in [ITUT-G841]. Given the stringent protection and restoration requirements, there is a strong need for developing a lightweight O-APS protocol, functionally viewed as an optical equivalent of the ubiquitous SONET/SDH APS (Automatic Protection Switching) protocol. The O-APS protocol is an IP-based protocol and exploits the characteristics of rings to support optical ring protection on OCh level initially and on OMS level in a future revision. It should be noted that the O-APS protocol performs only protection signaling upon fault events and not setup provisioning or fault detection. This protocol can be considered as an orthogonal addition to the GMPLS protocols suite to achieve fast protection signaling. The O-APS protocol does not propose any change or enhancement to the current APS specification as defined in ITU-T G.841 recommendation for existing SONET/SDH rings. Overall, the O-APS protocol is a specialized automatic protection switching protocol designed for optical rings and adopts an operational model similar to that of SONET/SDH. Note that two diverse lightpaths for 1+1 or 1:1 mesh protection can be viewed as a logical Optical Channel Dedicated Protection Ring (OCh DPRing). Due to this shared characteristic between path level 1+1 or 1:1 protection schemes and the OCh DPRing protection scheme, the O-APS protocol can also be used for mesh networks. This draft first describes the motivation for introducing the O-APS protocol. We then shift the focus to the requirements (including architectural, functional, and operational requirements) of the O-APS protocol. Subsequently, the O-APS protocol engine and particularly the related O-APS message formats are also briefly specified. 4. Motivation for the O-APS Protocol This section describes the motivations for developing an O-APS protocol. 4.1 Support for Unique Protection Features of Optical Networks The unique protection features of optical rings are specified in the ITU-T G841 (and additional information can be found in Telcordia GR-2979 document). To operators, a major attraction of optical rings is their inherent ability to provide fast protection and restoration. Expectedly, operators will likely demand stringent "SONET/SDH-like" protection performance for related optical rings. The unique protection switching features and requirements for optical rings warrant a specialized lightweight O-APS protocol. Additionally, because two diverse lightpaths in mesh networks can form a logical Optical Dedicated Protection Ring (OCh-DPRing), the O-APS protocl designed for optical rings can also be used to support path level 1+1 (bidirectional) or 1:1 linear protection schemes. Internet Draft D. Guo et al, draft-guo-optical-aps-01.txt [Page 2] 4.2 Interoperability at Optical Ring Level Given the large number of equipment providing optical rings capabilities, there is a strong need for multi-vendor interoperability at the optical ring level. Hence a standard-based O-APS protocol will facilitate interoperability amongst equipment from different vendors. 4.3 Enabling Efficient Operational Control Functionally, the O-APS protocol can be viewed as an optical equivalent of the field-proven SONET/SDH APS protocol. Operators have accumulated significant OAM&P experience with SONET/SDH APS. We choose to adopt an operational model for O-APS similar to that of SONET/SDH APS. 4.4 Performance Consideration The performance benchmark for protection switching that is commonly cited is protection switching within a 50 ms time window (as derived from SONET/ SDH). Admittedly this is a challenging task for optical network designers. In order to minimize overhead, the O-APS protocol is purposely built for optical rings with no dependence on existing MPLS signaling protocols such as CR-LDP for instance. It only performs protection signaling upon fault events and not any setup provisioning. Furthermore, it is independent of the exact fault detection module, as this is closely related to the underlying specific technology. 5. O-APS Requirements This section describes the protocol requirements for O-APS, including architectural, functional and operational requirements. As expected, various technology-specific design issues are intentionally left open in order to permit proprietary value-added implementation. 5.1 Overview of Optical Rings An optical ring is defined as a two or four fiber ring on which all of nodes are either dynamic OADM or OXC nodes. These network elements can utilize all-optical (i.e., transparent) or opto-electronic (i.e., opaque) designs (see [GHANI]). Optical ring protection switching schemes have been specified in various standards documents (e.g., ITU-T G.841) with additional information in Telcordia Generic Requirement documents GR 2979, GR 2918). The various possible optical rings are listed as follows: - Optical Channel Dedicated Protection Ring (OCh-DPRing). Dedicated protection can also be provided through single optical Channel (1+1) Sub-network Connection Protection (OCh-SNCP). Note that two diverse lightpaths provisioned in mesh networks can be viewed as a logical Optical Dedicated Protection Ring (OCh-DPRing) (see [PAPAD]). - Optical Channel Shared Protection Ring (OCh-SPRing) or O-BPSR (Optical Bi-directional Path Switched Ring) exist in two flavors, 2-Fiber O-BPSR (O-BPSR/2) and 4-Fiber O-BPSR (O-BPSR/4). Additionally, there are two switching strategies, ring switching (2- and 4-Fiber) and span switching (4-Fiber only). Internet Draft D. Guo et al, draft-guo-optical-aps-01.txt [Page 3] - Optical Multiplex-Section Dedicated Protection Ring (OMS-DPRing) or Optical Unidirectional Line Switched Ring (O-ULSR). - Optical Multiplex-Section Shared Protection Ring (OMS-SPRing) or Optical Bi-directional Line Switched Ring(O-BLSR ) exists in 2 variants, namely 2 Fiber O-BLSR (O-BLSR/2) and 4-Fiber O-BLSR (O- BLSR/4). Additionally, there are two switching strategies here, ring switching and span switching. For more details on optical ring protection switching schemes, refer to [PAPAD] and [GHANI]. 5.2 O-APS Functional Requirements The O-APS protocol will support the protection and restoration features outlined above. In this draft, we limit the scope to ring protection at the optical channel (OCh) level, but will expand the scope to include support at the OMS level in future revisions. The ring protection at the OCh level provides an efficient support for path-level 1+1 and 1:1 mesh protection schemes through logical rings (or ring emulations). For detailed discussions regarding ring emulations of mesh networks, see [PAPAD]. For optical rings, three types of traffic are considered: - Normal traffic carried on working channel and protected by O-APS; - Extra traffic, carried on protection channel and preemptible; - Non-preemptible Unprotected Traffic (NUT). 5.3 O-APS Architectural Requirements There are several possibilities that can be taken into account when designing the O-APS protocol. For example, it can be frame-based and built on top of the data link layer, or packet-based and built on top of IP. Each of these approaches has its advantages and disadvantages. In this draft, we use a packet-based approach, i.e., the O-APS protocol is directly layered on top of raw IP (instead of TCP or UDP). The protocol number for O-APS is to be assigned. Furthermore, it is assumed that O-APS packets are transported on the control channels supporting IP datagram transport such as IP/PPP/HDLC encapsulation, through the optical supervision channels (OSC), for instance. It should be noted that when using OSC for transporting O-APS packets, O-APS packets must be assigned the highest priority for expedited processing. Internet Draft D. Guo et al, draft-guo-optical-aps-01.txt [Page 4] Additionally, the O-APS protocol must provide a fast dedicated "hello" mechanism for optical rings. This "hello" mechanism is for inter-node keep- alive messaging purpose, enabling the rapid detection of control channel failures. Functionally, this is similar to non-alarm K1/K2 byte fields in the SONET/SDH APS protocol and the "hello" message defined in the Link Management Protocol (LMP) fast lightweight Hello protocol specification (see [LMP]). Finally, note that due to reliability considerations, the O-APS protocol also introduces retransmission mechanism. Specifically, after an O-APS message is sent, it is also added into a re-transmission queue associated with a timer. Since the protocol is IP-based, a fast re-transmission mechanism must be provided. For example, an O-APS message can be lost when transported over the control channel. Therefore, under normal operation, an O-APS message will be acknowledged via another O-APS message. The exact message exchange mechanisms (including retransmission, acknowledgement, and time-out) are intricately associated with the details of the finite-state machine (FSM) of the protocol engine. 5.4 Protection Switching Performance Requirements The O-APS protocol needs to achieve reliability and recovery performance levels that are comparable to those of the traditional SONET/SDH APS protocol. 1) Switch time. In an optical ring with no extra traffic and all nodes in the idle state (i.e., no detected failures, no active automatic. or external commands), the ring and span switching completion time for a failure on a single span shall be less than 50 ms. On rings under all other conditions, the switching completion time can exceed 50 ms in order to allow time for removing extra traffic, or for negotiating co-existed O-APS requests. Note that the protection switching completion time excludes the fault detection time necessary to initiate the protection switching. 2) Extent of protection. O-APS protection shall restore all normal traffic (i.e., excluding extra traffic and NUT) which has been interrupted due to failure of a link connection and that has been designated as forming part of an optical ring protection scheme. 5.5 O-APS Operational Requirements The O-APS protocol adopts an operational model similar to that of SONET/ SDH APS. This will assist the migration to optical rings, owing to the wide-spread adoption of SONET/SDH APS. The O-APS protocol should also allow operators to set up switch initiation criteria. The following initiation features shall be supported: - Signal Failure (SF); - Signal Degrade (SD); - Reverse Request; - Wait-To-Restore. The operational modes for O-APS are the following: Internet Draft D. Guo et al, draft-guo-optical-aps-01.txt [Page 5] - Revertive/non-revertive modes: Revertive mode shall be provided. In this mode, when protection is no longer requested (i.e., the failed working section is no longer in SD or SF condition) and assuming that no other requesting sections exist, a local wait-to-restore state shall be activated. A switch shall only revert to the working channels and not to a different set of protection channels. - Operator-control. The following externally initiated commands shall be supported: 1) Lockout, 2) Forced Switch, and 3) Manual Switch. Note that the O-APS protocol can work with a centralized provisioning solution since it is decoupled from GMPLS. This feature is useful because some operators may want to deploy the O-APS protocol on non-GMPLS capable devices. Despite the above-mentioned similarities, O-APS and SONET/SDH APS are distinctly different. The APS protocol is designed for SONET/SDH networks whereas the O-APS protocol is intended only for OCh rings and mesh networks. The APS protocol for SONET/SDH (as well as in the future ODU and OTU Rings) is performed via in-band signaling whereas the O-APS protocol is designed to be IP-based. Fundamentally, these two protocols support different protection switching mechanisms. 6. O-APS Protocol Engine 6.1 Architecture The overall O-APS protocol interworking architecture is described in the following diagram: +--------------------+ +-------------------+ | O-APS Protocol | | Resource/TE | | Engine |<------------> | Manager | +--------------------+ +-------------------+ ^ ^ | | v v +--------------------+ +-------------------+ | Control Channel | | Performance | | Device Driver | | Monitor (PM)/ | | | | Fault manager | +--------------------+ +-------------------+ Fig 1. O-APS Interworking Diagram The O-APS protocol engine works either with a centralized resource/ traffic engineering (TE) manager or with a distributed resource/traffic (TE) engine. The entity maintains all information regarding the ring map and the protection groups provisioned at a node. In the former case, the information is configured through a management terminal while in the latter case, it can be discovered/disseminated through mechanisms clearly outside of the scope of this specification. Meanwhile, the performance monitor and fault manager monitors the light- paths at a node and triggers fault events towards the resource/TE manager. O-APS events can be triggered locally and relayed to the O-APS protocol engine. Internet Draft D. Guo et al, draft-guo-optical-aps-01.txt [Page 6] When a new protection group is provisioned or a protection group under- goes any change in status (i.e., during faults, forced deletions, or modifications regarding protection path and working path), the resource/ TE manager notifies the O-APS protocol engine. Note that O-APS messages can be sent to and received from other nodes via the control channel. 6.2 O-APS Protocol Description The O-APS protocol engine has a related finite state machine (FSM) that coordinates the O-APS event-handling and state transition. It is possible to devise separate FSMs for different optical ring protection switching schemes (e.g., there would be one FSM for OCh DPRing and another FSM for OCh SPRing). This strategy is both effective and necessary, due to the unique features of each optical ring protection scheme. For each protection scheme, there are various specific O-APS events. Due to their complexity, we will leave those for a future revision of this draft. Note that it is possible to devise different ways to represent the internal states and thus different FSM entities for the same protocol. This aspect leads us to act cautiously on standardizing the O-APS events, states, and FSMs. As an example, in this draft, we list the following events and states for OCh-DPRing: OAPS_CONNECTION_FAIL: Primary-connection fails; OAPS_CONNECTION_TEAR: Protection group is torn down; OAPS_BRIDGE_REQUEST: Bridge-request for this protection group; OAPS_BRIDGE_INDICATION: Bridge-indication for this protection group; OAPS_SWITCH_CONFIRM: Switch-confirm for this protection group; OAPS_BRIDGE: Inform OXC to "bridge" at source node; OAPS_SWITCH: Inform OXC to "switch" at sink node; OAPS_TIME_OUT: Timer expiration OAPS_ERROR: Invalid event OCh-DPRing handles each protection group independently. A protection group consists of a primary (working) path and a secondary (protection) path. Note that here the terms "bridge" and "switch", commonly used in SONET/SDH APS terminology, have different meanings. Specifically, "bridge" refers to conducting protection switching at the source node of a uni- directional path and "switch" refers to conducting protection switching at the sink node of a uni-directional path. OCh-DPRing will have 6 major FSM states, each of which could have further sub-states: OAPS_PG_INIT: Protection group is in idle state OAPS_PG_BRIDGE_INITIATED: Protection group is in bridge-initiated state; OAPS_PG_BRIDGED: Protection group is in bridged state; OAPS_PG_SWITCHED: Protection group is in switched state; OAPS_PG_BRIDGED_SWITCHED: Protection group is in bridged/switched state; OAPS_PG_FAIL, Protection group is in failure state. Internet Draft D. Guo et al, draft-guo-optical-aps-01.txt [Page 7] To illustrate the behavior of O-APS for OCh-DPRing, a potential interaction between an O-APS protocol engine and a resource manager is described: 1. When a new protection group is provisioned, the resource manager informs the O-APS protocol engine which sets up an internal "control" block with a state "OAPS_PG_INIT"; 2. When a fiber span of a working connection fails, an "OAPS_CONNECTION_ FAIL" event will be detected at the sink node (say node A). Here, a "BRIDGE-REQUEST" event is generated, packaged into an O-APS message, and sent via the control channel to the source node (say node B) of this connection. Subsequently, the state is transited to "OAPS_PG_BRIDGE _INITIATED" for this protection group. As in SONET/SDH APS, actually two messages are sent around the ring, one east bound and the other west bound. The event types (and additional information) are coded into CK1/CK2 bytes of an O-APS message (see section 7); 3. Upon receiving a "BRIDGE-REQUEST" event, the source node (node B) will conduct protection switching and transition to "OAPS_PG_BRIDGED" state. Subsequently, node B triggers an "OAPS_BRIDGE_INDICATION" event and an O-APS message towards node A. 4. Upon receiving "OAPS_BRIDGE_INDICATION", node A will send an event "OAPS_SWITCH" to tell the local OXC to perform protection switching. The above description handles only "half" of protection switching, since a connection is bi-directional. It also does not consider any message re- transmission and time-out mechanisms. The complete details of the FSM will be relegated to a future revision of this draft. 7. O-APS Packet Specification In this section, the O-APS protocol message format is described. The O-APS messages are encapsulated in IP packets and use an encoding scheme similar to that of SONET/SDH APS. Specifically, each O-APS message consists of a message header and message body, as detailed subsequently. 7.1 O-APS Packet Header Each O-APS message carries the following header: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version Number | Msg Type | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message sequences | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Currently, there are five types of O-APS protection messages. Internet Draft D. Guo et al, draft-guo-optical-aps-01.txt [Page 8] O-APS Msg Type Value ---------------------------- HELLO 1 OCh-DPRing 2 OCh-SPRing 3 OMS-DPRing 4 OMS-SPRing 5 7.2 O-APS Message Body Each O-APS event is encoded into an O-APS message. An O-APS message should contain a source ID, a destination ID, a connection ID and a protection group ID (PG ID). A protection group ID is to uniquely identify a protection group, of which multiple connections can be its members. In addition to the protection group ID, an O-APS message should contain CK1/CK2 code to represent specific network events and protection switching actions. Similar to SONET/SDH APS, these codes are split into two parts, termed CK1 and CK2, respectively. Both of these codes are two bytes each and defined as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Connection ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PG ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CK1 | CK2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ CK1 and CK2 Bytes CK1 byte Value ----------------------------------------------------- CK1_OAPS_CONNECTION_FAIL 0xD000 CK1_OAPS_BRIDGE_REQUEST 0x7000 CK1_OAPS_SWITCH_REQUEST 0xF000 CK1_OAPS_CONNECTION_UP 0x9000 CK1_OAPS_CONNECTION_DELETE 0xA000 CK1_OAPS_BRIDGE_INDICATION 0x6000 CK1_OAPS_SWITCH_CONFIRM 0x4000 CK1_OAPS_SWITCH_OK 0x5000 CK2 byte Value ------------------------------------------------------ CK2_LONG 1st bit =1 CK2_SHORT 1st bit =0. Internet Draft D. Guo et al, draft-guo-optical-aps-01.txt [Page 9] Here, "short" side is used to denote the "working" lightpath while the "long" side is used to denote the "protection" lightpath. In case of failure, two messages are exchanged: "short" is send over the failed link, while long is sent along the ring for ring switch. We use the last bit of CK2 byte to indicate whether the sender of this O-APS message is the source node of the protection group: - 16th bit of CK2=0: sender is the initiating node of a protection request; - 16th bit of CK2=1: sender is the destination node of a protection request. This bit is termed as "direction" bit. Meanwhile, the actual CK2 byte is coded as follows: CK2 byte value ------------------------------------------------------ CK2_LONG and as Source node 0x8000; CK2_LONG and as Destination node: 0x8001; CK2_SHORT and as Source node: 0x0000; CK2_SHORT and as Destination node: 0x0001. Additional CK1/CK2 codes can be defined in a future revision. Note that SONET/SDH K1/K2 codes can also be mapped into these O-APS CK1/CK2 fields. 8. Fault Detection Fault detection mechanisms are independent of the protection and restoration protocol. There will be information exchange between the fault detection module and the O-APS protocol engine (as illustrated in Fig 1). The O-APS protocol will interwork with the emerging LMP protocol [LMP]. LMP provides generic fault correlation and notification functionalities that are independent of the actual fault detection schemes. Recent proposals for new WDM related considerations within the LMP framework [LMP-WDM] will help improve its scalability and fault notification timings in optical ring networks. Switching triggers and mapping of LMP notifications to O-APS need to be defined, and this work is left for further investigation. 9. Security Considerations Security considerations are for future study. Overall, it poses the same security requirements as those present in the SONET/SDH APS. Internet Draft D. Guo et al, draft-guo-optical-aps-01.txt [Page 10] 10. References [GR-2979] "Common Generic Requirements for Optical Add-Drop Multiplexers (OADMs) and Optical Terminal Multiplexers (OTMs), GR-2979-Core, Telcordia Generic Requirement Documents. [ANSI-T1.105] "Synchronous Optical Network (SONET): Basic Description Including Multiplex Structure, Rates, and Formats," ANSI T1.105, 2000. [CVIJETIC1] M. Cvijetic, T. Shiragaki, "Standardization of OCh Shared Protection Ring and Its Open Issue List," T1X1 Forum, T1X1.5/99-255R1, October 1999. [GHANI] N. Ghani, et al, "Architectural Framework for Automatic Protection Provisioning In Dynamic Optical Rings", draft-ghani-optical-rings-01.txt, Internet Drafts, March 2001. [GMPLS-ARCH] E. Mannie, et al., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", Internet Draft, Work in progress, draft-many-gmpls-architecture-00.txt, February 2001. [GMPLS-G709] A. Bellato, et al., "Generalized MPLS Signaling Extensions for G.709 Optical Transport Networks", Internet Draft, Work in progress, draft-fontana-ccamp-gmpls-g709-01.txt, Nov 2001. [GMPLS-RSVP] P. Ashwood-Smith, et al., "Generalized MPLS Signaling - RSVP-TE Extensions", Internet Draft, Work in progress, draft-ietf- mpls-generalized-rsvp-te-03.txt, May 2001. [GMPLS-SIG] P. Ashwood-Smith, et al., "Generalized MPLS - Signaling Functional Description", Internet Draft, Work in progress, draft-ietf- mpls-generalized-signaling-04.txt, May 2001. [LMP-WDM] A. Fredette, et al, "Link Management Protocol (LMP) for WDM Transmission Systems," Internet Draft, draft-fredette-lmp-wdm-01.txt, March 2001. [LMP] J. Lang, et al, "Link Management Protocol (LMP)," Internet Draft, Work in progress, draft-ietf-mpls-lmp-02.txt, March 2001. [PAPAD] D. Papadimitriou, "Optical Rings and Hybrid Mesh-Ring Optical Networks", draft-papadimitriou-optical-rings-02.txt, Internet Drafts, Work in progress, Nov 2001. 11. Author's Addresses Dan Guo, Jibin Zhan, Wenjing Chu, Hui Zhang Turin Networks, Inc. 1415 N. McDowell Blvd, Petaluma, CA 95454 Phone: +1 707-665-4357 Email: {dguo,jzhan,wchu,hzhang}@turinnetworks.com Nasir Ghani, James Fu, Zhensheng Zhang Sorrento Networks, Inc. 9990 Mesa Rim Road, San Diego, CA 92121 Email: {nghani,jfu,zzhang}@sorrentonet.com Dimitrios Pendarakis Tellium Optical System 2 Crescent Place, Oceanport, NJ 07757-0901 Email: DPendarakis@tellium.com Sudheer Dharanikota Nayna Networks, Inc. 157 Topaz Street, Milpitas, CA 95035, USA Email: sudheer@nayna.com Internet Draft D. Guo et al, draft-guo-optical-aps-01.txt [Page 11] Dimitri Papadimitriou Alcatel IPO-NSG B-2018 Antwerpen, Belgium Phone: +32 3 240-8491 dimitri.papadimitriou@alcatel.be Stefan Ansorge Alcatel SEL AG Lorenzstrasse 10, 70435 Stuttgart, Germany Phone: +49 7 11 821 337 44 Email: Stefan.ansorge@alcatel.de 12. Full Copyright Notice Copyright (C) The Internet Society (1997). All Rights Reserved. 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 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 is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Internet Draft D. Guo et al, draft-guo-optical-aps-01.txt [Page 12]