Internet Draft	                                Dan Guo, Jibin Zhan, 
draft-guo-optical-aps-00.txt                    Wenjing Chu, Hui Zhang
July 2001       		                (Turin Networks)
	
						Nasir Ghani, James Fu, 
						Zhensheng Zhang
						(Sorrento Networks)
	
						Dimitrios Pendarakis 
						(Tellium)

Expiration Date: Jan 2002			Sudheer Dharanikota 
						(Nayna Networks)


     Optical Automatic Protection Switching Protocol (O-APS) 
        	   <draft-guo-optical-aps-00.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with all  
   provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering Task 
   Force (IETF), its areas, and its working groups. Note that other groups 
   may also distribute working documents as Internet-Drafts. Internet-
   Drafts are draft documents valid for a maximum of six months and may be 
   updated, replaced, or obsoleted by other documents at any time. It is 
   inappropriate to use Internet-Drafts as reference material or to cite 
   them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://www.ietf.
   org/ietf/1id-abstracts.txt. 

   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html.

1. Abstract

   We describe an optical automatic protection switching protocol (O-APS) 
   for optical rings. Specifically, the O-APS protocol is an IP-based 
   light-weight 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 mesh 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 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 APS protocol, due to the 
   wide-spread adoption of SONET 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-00.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 [GR-2979]. 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 using K1/K2 bytes. 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 per-
   forms only protection signaling upon fault events and not setup pro-
   visioning or fault detection. This protocol can be considered as an 
   orthogonal addition to the GMPLS protocols suite to achieve fast 
   protection signaling.
   
   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 mesh 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 Telcordia GR-2979 documents. 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. To date, however, an optical protection switching protocol for 
   optical rings has not been defined. 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 or 1:1 mesh protection schemes.


Internet Draft	 D. Guo et al, draft-guo-optical-aps-00.txt     [Page  2]



4.2 Interoperability at Optical Ring Level

   Given the large number of equipment vendors building optical rings, 
   there is a strong need for multi-vendor interoperability at the optical 
   ring level. Here the O-APS protocol definition will increase interoper-
   ability 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. Addition-
   ally, O-APS will facilitate network management required for efficient 
   operational control of optical ring networks. 

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 miminize overhead, the O-APS protocol is purposely built for 
   optical rings with no dependence on GMPLS. 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 and 
   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-00.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.

   Furthermore, related equivalence between linear (mesh networks) and ring 
   protection schemes is presented in the following table:

                                Linear Protection   Ring Protection
   --------------------------------------------------------------------
   Dedicated Line Protection    (1+1, 1:1)            OMS-DPRing
   Shared Line Protection         (1:N)               OMS-SPRing
   Dedicated Path Protection    (1+1, 1:1)            OCh-DPRing
   Shared Path Protection         (1:N)               OCh-SPRing

   For more details on optical ring protection switching schemes, refer to 
   [GR 2979] 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 control 
   channels, through the optical supervision channels (OSC). (Although in-band 
   signaling through digital wrapper overheads is another choice, this is left 
   for future study). 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-00.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) (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 is required. 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, recovery and restoration 
   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 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-00.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 GMPLS-based control plane at 
   later time.

   Despite the above-mentioned similarities, O-APS and SONET/SDH APS are 
   distinctly different. In particular, SONET/SDH APS is designed for TDM 
   networks whereas O-APS is intended for optical WDM rings. SONET/SDH APS 
   is performed via in-band signaling whereas O-APS 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 very closely with resource/traffic 
   engineering (TE) manager. The latter entity maintains all information 
   regarding the ring map and the protection groups provisioned at a node. 
 
   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-00.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-00.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 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 K1/K2 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 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 |O-APS 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-00.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 protection group identifier (PG ID) to uniquely identify a 
   protection group. A PG ID consists of the source ID, the destination ID 
   and the connection ID (assigned when a connection is provisioned). 

   In addition to the protection group ID, an O-APS message should contain 
   K1/K2 code to represent specific network events and protection switching
   actions. Similar to SONET APS, these codes are split into two parts, termed 
   K1 and K2, 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                         |
   +---------------------------------------------------------------+   
   |   K1                         |   K2                           |
   +---------------------------------------------------------------+

   K1 and K2 Bytes

             K1 byte                     Value
          -----------------------------------------------------
	  K1_OAPS_CONNECTION_FAIL        0xD000
	  K1_OAPS_BRIDGE_REQUEST         0x7000
	  K1_OAPS_SWITCH_REQUEST         0xF000
	  K1_OAPS_CONNECTION_UP          0x9000
	  K1_OAPS_CONNECTION_DELETE      0xA000
	  K1_OAPS_BRIDGE_INDICATION      0x6000
	  K1_OAPS_SWITCH_CONFIRM         0x4000
	  K1_OAPS_SWITCH_OK              0x5000


            K2 byte                     Value
          ------------------------------------------------------
          K2_LONG                      1st bit =1
          K2_SHORT                     1st bit =0.

   Here, "short" side is used to denote the "working" lightpath while the 
   "long" side is used to denote the "protection" lightpath. We use the 
   last bit of K2 byte to indicate whether the sender of this O-APS message
   is the source node of the protection group:


Internet Draft	 D. Guo et al, draft-guo-optical-aps-00.txt   [Page 9]




    - 8th bit of K2=0: sender is the source node of a protection group;
    - 8th bit of K2=1: sender is the destination node of a protection group. 

   This bit is termed as "direction" bit. Meanwhile, the actual K2 byte is 
   coded as follows:
          
            K2 byte                              value
          ------------------------------------------------------
          K2_LONG and as Source node            0x8000;
          K2_LONG and as Destination node:      0x8001;
          K2_SHORT and as Source node:          0x0000;
          K2_LONG and as Destination node:      0x0001.

   Additional K1/K2 codes can be defined in a future revision. Note that 
   SONET/SDH K1/K2 codes can also be mapped into these O-APS K1/K2 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 APS.

10 Acknowledgements

   We would like to thank D. Papadimitriou of Alcatel at Belgium for 
   helpful discussions and feedbacks during the course of writing this 
   draft. 

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



Internet Draft	 D. Guo et al, draft-guo-optical-aps-00.txt   [Page 10]



[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 Signalling
Extensions for G.709 Optical Transport Networks", Internet Draft,
Work in progress, draft-fontana-ccamp-gmpls-g709-00.txt, June 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-01.txt, Internet Drafts, 
Work in progress, May 2001.

12. 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-00.txt   [Page 11]



13. 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-00.txt   [Page 12]