Internet DRAFT - draft-guo-optical-aps
draft-guo-optical-aps
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)
<draft-guo-optical-aps-01.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
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]
