Internet DRAFT - draft-bala-mpls-optical-uni-signaling
draft-bala-mpls-optical-uni-signaling
Internet Draft Osama S. Aboul-Magd
draft-bala-mpls-optical-uni-signaling-01.txt Nortel Networks
Expiration : May, 20, 2001 Olga Aparicio
Cable & Wireless USA
Rick Barry
Sycamore Networks
Greg Bernstien
Ciena
Raj Jain
Nayna Networks
LiangYu Jia
Rajiv Dulepet
ONI Systems
Monica Lazer
Jennifer Yates
AT&T
Dimitrios Pendarakis
Bala Rajagopalan
Tellium, Inc.
Robert Rennison
Laurel Networks
Yangguang Xu
Lucent Technologies
Yong Xue
UUNET/Worldcom
John Yu
Zaffire, Inc.
Zhensheng Zhang
Sorrento Networks
Signaling Requirements at the Optical UNI
1. 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.
Page 1 of 16
draft-bala-mpls-optical-uni-signaling-01.txt
2. Abstract
This draft considers the optical network service model referred
to as the "domain services" model [1]. Under this model, the optical
network provides a set of well-defined services to clients (IP and
others). The signaling and routing interface between the client and
optical networks is referred to as the User-Network Interface (UNI).
This draft describes the services provided over the UNI, and the
requirements on any signaling protocol used to invoke the services.
This draft reflects ongoing work at the Optical Interworking Forum
(OIF) on the optical UNI (similar work is being carried out by the
Optical Domain Services Interconnect (ODSI) coalition [2]). The
relevance of this draft to the IETF is two-fold. First, for the
signaling portion of the optical UNI, extensions of two MPLS
signaling protocols are presently under consideration in the OIF:
RSVP with TE extensions and LDP. The objective of this draft is to
guide the adaptation of these protocols for UNI signaling. Second,
to harmonize the signaling of UNI originated lightpath requests and
peer model lightpath establishment mechanisms [1], alignment between
OIF and IETF lightpath parameters and signaling functionality is
desirable. This draft aims to serve this purpose. The content of
this draft is expected to evolve as work progresses on the optical
UNI.
3. Introduction
The network model considered in this draft consists of client
networks (IP and others) attached to an optical core network, and
connected to their peers over dynamically established switched
lightpaths. The optical core itself is assumed to be incapable of
processing individual IP packets.
The optical network is assumed to consist of multiple optical
sub-networks interconnected by optical links in a general topology
(referred to as an optical mesh network). This network may be multi-
vendor. Each sub-network itself contains a mesh-connected set of
optical cross-connects (OXCs). This network model is shown in Figure
1.
There are two logical control interfaces identified in Figure 1.
These are the client-optical network interface, and the optical sub-
network interface. These interfaces are also referred to as the
User-Network Interface (UNI) and the Network-Network Interface
(NNI). In this draft, the focus is on the UNI.
Expires on 5/24/01 Page 2 of 16
draft-bala-mpls-optical-uni-signaling-01.txt
Optical Network
+---------------------------------------+
| |
+--------------+ | |
| | | +------------+ +------------+ |
| IP | | | | | | |
| Network +--UNI--+ Optical +---NNI--+ Optical | |
| | | | Subnetwork | | Subnetwork | |
+--------------+ | | | +-----+ | |
| +------+-----+ | +------+-----+ |
| | | | |
| NNI NNI NNI |
+--------------+ | | | | |
| | | +------+-----+ | +------+-----+ |
| IP +--UNI--| +--+ | | |
| Network | | | Optical | | Optical | |
| | | | Subnetwork +---NNI--+ Subnetwork | |
+--------------+ | | | | | |
| +------+-----+ +------+-----+ |
| | | |
+-------UNI-------------------UNI-------+
| |
| |
+------+-------+ +------------+
| | | |
| Other Client | |Other Client|
| Network | | Network |
| (e.g., ATM) | | |
+--------------+ +------------+
Figure 1: Optical Network Model
The physical control structure used to realize the logical UNI may
vary. For instance, some of the possibilities are:
1. Direct Interface: An in-band or out-of-band IP control channel
(IPCC) may be implemented between a client and each OXC that it
connects to. With in-band signaling, the signaling messages are
carried over a logical communication channel embedded in a
physical optical link between the client device and OXC. For
example, this could be the overhead bytes in the SONET frame or a
dedicated optical wavelength. With out-of-band signaling, the
signaling messages are transmitted over a separate communication
infrastructure that is independent of the optical data links
between the client devices and OXC. For example, this could be a
LAN/WAN based network infrastructure separate from the optical
network.
Expires on 5/24/01 Page 3 of 16
draft-bala-mpls-optical-uni-signaling-01.txt
This control channel, in-band or out-of-band, is used for
exchanging signaling and routing messages directly between the
client and the OXC. With a direct interface, the client and the
OXC it connects to support the control plane information exchange.
This is shown in Figure 2.
+-----------------------------+ +-----------------------------+
| | | |
| +-----------------------+ | | +-----------------------+ |
| | | | | | | |
| | UNI Signaling | | | | UNI Signaling | |
| | | | | | | |
| +-----+-----------+-----+ | | +-----+-----------+-----+ |
| | | | | | | |
| | | | | | | |
| +--+-----------+---+ | | +--+-----------+---+ |
| | | | | | | |
| | IP Layer +......IPCC.......+ IP Layer | |
| | | | | | | |
| +------------------+ | | +------------------+ |
| | | |
| Client | | OXC |
+-----------------------------+ +-----------------------------+
Figure 2: Direct Interface
2. Indirect interface: An out-of-band IP control channel may be
implemented between the client and a controlling device in the
optical network to signal service requests and responses. For
instance, a control plane server in the optical network may
receive service requests from clients. Similarly, out-of-band
signaling may be used between a device in the client network
(e.g., a management system) and the OXC, or between devices in
client and optical networks to signal service requests. In these
cases, there is no direct control interaction between clients and
respective OXCs. One reason to have an indirect interface would be
that the OXCs and/or clients do not support a direct interface.
It is essential that both direct and indirect interfaces be
supported by any UNI signaling protocol. Under both these
interfaces, the entity that performs UNI signaling on the client
side is referred to as UNI-C. The corresponding entity on the
network side is referred to as UNI-N. In the case of the direct
interface, each client device attached to the optical network will
have a UNI-C instance and each OXC attached to a client will have a
UNI-N instance. In the case of the indirect interface, these
entities may be located outside of the client device and OXC, as per
the description in (2) above.
Expires on 5/24/01 Page 4 of 16
draft-bala-mpls-optical-uni-signaling-01.txt
In the following, the service definition and signaling requirements
for realizing the UNI are described.
4. Optical Network Services
The optical network primarily offers discrete capacity, high
bandwidth connectivity in the form of lightpaths. A lightpath is
established between two termination points in the optical network,
to which client devices are attached. The properties of the
lightpaths are defined by the attributes specified during lightpath
establishment or via acceptable modification requests.
The notion of "user groups" are considered as integral to lightpath
establishment in this draft. A user group defines a community of
client devices with restrictions on connectivity from devices
outside this group. The requirements on lightpath termination point
and user group identification are described in the next section.
The following actions support lightpath services:
1. Lightpath creation: This action allows a lightpath with the
specified attributes to be created between a pair of termination
points. Each lightpath is assigned a unique identifier by the
optical network, called the lightpath ID, which is used in UNI
signaling messages to reference the lightpath in further
transactions. Lightpath creation may be subject to network-
defined policies (e.g., user group connectivity restrictions) and
security procedures.
2. Lightpath deletion: This action allows an existing lightpath
(referenced by its ID) to be deleted.
3. Lightpath modification: This action allows certain parameters of
the lightpath (referenced by its ID) to be modified. Lightpath
modification may be subject to network-defined policies. Lightpath
modification must be non-destructive, i.e., the success or failure
of the modification procedure must not result in the loss of the
original lightpath.
4. Lightpath status enquiry: This service allows the status of
certain parameters of the lightpath (referenced by its ID) to be
queried.
Additionally, the following address resolution procedures may be
made available over the UNI (more sophisticated routing information
exchange over the UNI is covered in [3]):
1. Client Registration: This allows a client to register its
address(es) and user group identifier(s) with the optical
network. The registered address may be of different types, IP,
ATM NSAP, E.164, etc. The optical network associates the client
address and user group ID with an optical-network-administered
address.
Expires on 5/24/01 Page 5 of 16
draft-bala-mpls-optical-uni-signaling-01.txt
2. Client De-Registration: This allows a client to withdraw its
address(es) and user group identifier(s) from the optical
network.
3. Query: This allows a client to supply another clientÆs native
address (e.g., ATM) and user group ID, and get back an optical-
network-administered address that can be used in lightpath create
messages.
An end-system discovery procedure may be used over the UNI to verify
local port connectivity between the optical and client devices, and
allows each device to bootstrap the UNI control channel. Finally, a
"service discovery" procedure may be employed as a precursor to
obtaining UNI services. Service discovery allows a client to
determine the static parameters of the interconnection with the
optical network, including the UNI signaling protocols supported.
The protocols for neighbor and service discovery are different from
the UNI signaling protocol itself (for example, see LMP [6]).
With regard to address resolution, the registration and de-
registration procedures may be implemented using service discovery
mechanisms. The query mechanism may be implemented as an additional
UNI signaling procedure.
5. Identification of Lightpath Termination Points and User Groups
It is assumed that each OXC in an optical network has one or more IP
addresses assigned to it. The address assigned to an OXC is assumed
to be unique within the service domain that supports the UNI. These
addresses are referred to as optical-network-administered addresses.
A client point of attachment to the optical network is associated
with an optical-network-administered address. It is possible that
more than one point of attachment may be associated with the same
optical-network-administered address. Lightpath creation messages
must identify the source and destination client points of
termination. If these termination points cannot be uniquely
identified by an IP address alone, another address component, called
the "logical port ID" may optionally be specified. Thus, the full
client termination point identification consists of two components,
an IP address and an optional logical port ID. The logical port ID
consists of the physical port, and channel and sub-channel
identifiers unique to a specific OXC (that can be reached using the
IP address component). Because the logical port ID is of local
significance only, it must be unique only with respect to a specific
OXC. Furthermore, the logical port ID is not used for routing a
lightpath within the optical network, but only to identify a
termination point within an OXC.
It is required that every client be assigned one or more user group
identifiers. User group identification allows the formation of
closed user groups, or virtual private networks of clients. The user
Expires on 5/24/01 Page 6 of 16
draft-bala-mpls-optical-uni-signaling-01.txt
group identifier(s) for each client-optical interface is registered
during UNI service discovery. The format of the user group
identifier is the same as the VPN identifier defined in [4].
6. Signaling Requirements
This section describes the mechanisms that must be available in a
UNI signaling protocol.
6.1 IP Control Channel
An IP control channel is required between the UNI-C and the
corresponding UNI-N entities. To implement the control channel, it
is necessary for the UNI-C and the UNI-N entities to know each
other's IP address. In the case of the direct interface, the UNI
neighbor discovery protocol is used for this. The same protocol
would allow the optical network to identify the client and apply any
policies that may relate to the establishment of the UNI control
channel. In the case of the indirect interface, the IP address
information must be configured administratively.
An in-band or an out-of-band transport link should exist between
UNI-C and UNI-N to establish the control channel. To use such a link
for the UNI control channel, the following requirements must
be met:
o The link must be able to carry IP packets from UNI-C to UNI-N;
o The bit rate and minimum transfer size (in bytes) of the link must
be adequate to support this function;
o The link must be secure, or UNI-C and UNI-N must implement
procedures to recognize authorized messages and to prevent
unauthorized access;
o It must be possible for both UNI-C and UNI-N to detect the failure
of the link quickly.
In the case of direct interface, there could be multiple interfaces
between the client and the OXC. In this case, there need be only a
single active IP control channel between them. This control channel
can utilize any one of the many in-band and/or out-of-band transport
links between the devices. Furthermore, as long as there is at least
one link available, the UNI control channel must be maintained
without break.
The UNI-C and UNI-N entities must be able to determine quickly the
failure of an already established UNI control channel. The failure
of the control channel or the unreachability of the peer UNI
signaling entity does not imply the removal of established
lightpaths. On the other hand, since signaling can be initiated
from either side of the lightpath for lightpath deletion or
modification of certain parameters, it is possible for the
Expires on 5/24/01 Page 7 of 16
draft-bala-mpls-optical-uni-signaling-01.txt
lightpath state information to be different in the network and
client sides when the UNI control channel is not functional.
Thus, when the UNI control channel is affected by a failure (e.g.,
the failure of the transport link or the unreachability of the
peer UNI signaling module), a procedure to synchronize lightpath
state must be implemented after recovery.
6.2 UNI Signaling (Abstract) Messages
The UNI signaling messages that must be supported are described
below. These messages are denoted "abstract", in reference to
the fact that they may be realized in different ways depending on
the signaling protocol used. In the following description, the terms
"initiating UNI-C" and "terminating UNI-C" are used to identify the
entities at two ends of a lightpath that initiate and terminate
signaling actions. With the direct interface, a UNI-C entity at
either end of a lightpath can initiate a signaling action. The UNI-C
entity at the other end then becomes the terminating client. With
some indirect interfaces, the initiating and terminating UNI-C could
be the same entity.
1. Lightpath Create Request: Sent from the initiating UNI-C to UNI-N
to create a lightpath.
2. Lightpath Create Response: Sent from
a. the terminating UNI-C to UNI-N to accept an incoming lightpath
create request.
b. the UNI-N to the initiating UNI-C to indicate the successful
creation of (or failure to create) the lightpath as requested
in (1).
3. Lightpath Delete Request: Sent from
a. the initiating UNI-C to UNI-N to delete a lightpath.
b. the UNI-N to a UNI-C to indicate the deletion of a lightpath
by the network.
4. Lightpath Delete Response: Sent from
a. the terminating UNI-C to UNI-N to acknowledge an incoming
lightpath delete request.
b. the UNI-N to the initiating UNI-C to indicate the successful
deletion of the lightpath as requested in (3).
5. Lightpath Modification Request: Sent from the initiating UNI-C to
UNI-N to modify the specified lightpath parameters. Modification
must be non-destructive.
6. Lightpath Modification Response: Sent from UNI-N to the
Expires on 5/24/01 Page 8 of 16
draft-bala-mpls-optical-uni-signaling-01.txt
initiating UNI-C to indicate the successful modification of (or
failure to modify) the lightpath parameters requested in (5).
7. Lightpath Status Enquiry: Sent from
a. the initiating UNI-C to UNI-N to enquire about the status
and/or the parameters of the specified lightpath, or all
lightpaths owned by the UNI-C.
b. the UNI-N to either UNI-C to enquire about the status of
the parameters of the specified lightpath, or all lightpaths
owned by the UNI-C.
8. Lightpath Status Response: Sent from the UNI-N to the initiating
UNI-C to indicate the status of lightpath parameters as requested
in (7). Multiple "Lightpath Status Response" messages (one per
lightpath) may be sent by UNI-N when the initiating UNI-C requests
the status of all lightpaths terminating at a particular
interface.
9. Notification: This message is sent autonomously by UNI-N to UNI-C
to indicate a change in the status of the lightpath (e.g.,
unrestorable lightpath failure).
10. Address Query: This message is sent from the UNI-C to the
corresponding UNI-N to request the resolution of a remote client
network address to the corresponding optical-network-administered
IP address (and logical port ID, if assigned). The following
client network address types may be supported: IPv4, IPv6, ATM
NSAP, E.164, and British Standards Institute ICD AESA.
How these messages are mapped to actions within the optical network,
and the signaling protocol used within the optical network to
realize the actions are not concerns at the UNI. Furthermore, the
resolution of conflicts when UNI signaling is concurrently invoked
on both sides of a lightpath to perform certain actions (e.g.,
modify with conflicting parameters) is not considered to be a UNI
signaling issue.
6.3 UNI (Abstract) Message Parameters
The following parameters must be encoded in UNI signaling messages.
It is expected that formats for the parameters will be reconciled
with the format of similar parameters being developed for GMPLS
signaling [5]. The list below may evolve based on ongoing work in
OIF UNI signaling.
6.3.1 Identification
1. Lightpath ID: A network-wide unique 64-bit identifier for a
lightpath. This identifier is assigned by the optical network.
Expires on 5/24/01 Page 9 of 16
draft-bala-mpls-optical-uni-signaling-01.txt
2. Contract ID: A carrier-assigned identification that identifies
the service contract. This is part of the policy data carried
from the client to the network. The contract ID is a variable
length string passed from the client to the network.
3. Source/destination client point of attachment: This has two
components, an optical-network-administered IP address and an
optional logical port information. The latter consists of a port
index, a channel index and a sub-channel index.
4. User group ID: VPN identifier as defined in [4].
5. UNI-C ID: IP address of the UNI-C entity.
6.3.2 Service-Related
1. Directionality: Flag that indicates whether the lightpath is uni
or bi-directional. Default is bi-directional.
2. Framing type: Framing type specifies the format of the signal to
be transported across the UNI. The valid framing options
considered are SONET and SDH.
3. Overhead termination type: This attribute is framing specific. For
SONET and SDH framing this field specifies to what degree the
framing overhead bytes are terminated. The following values are to
be supported for UNI:
o signal without termination of any overhead;
o: signal with the possible termination of section overhead;
o: signal with the possible termination of section and line
overhead.
3. Bandwidth: This specifies the bandwidth of the service and is
interpreted w.r.t. the framing. Note that this is the bandwidth
of the service, not the bandwidth of the physical interfaces.
The latter may differ on each end of the connection.
o For SONET, the options are STS-1, STS-2,..., STS-768
o For SDH, the options are STM-1, STM-2, ... STM-256
It is part of the connection acceptance process of the optical
network to determine if the network and the physical interfaces at
the UNI can support the requested framing type, overhead
termination type and bandwidth.
Expires on 5/24/01 Page 10 of 16
draft-bala-mpls-optical-uni-signaling-01.txt
4. Propagation delay: This specifies the maximum acceptable
propagation delay in milliseconds. Defaults to infinity.
5. Service level: An integer specifying the service level
requested for the lightpath. Different service levels may be
defined by the optical network service provider, encompassing
priority, preemption, protection and other service-distinguishing
parameters. The "service level" parameter encodes the service
type and it is interpreted by the provider. Some values (e.g.,
0-255) should be reserved for future use. The remaining values
are provider specific. Default set by provider.
It is also possible that priority, preemption, etc., could be
separately specified as (optional) parameters.
6.3.3 Routing-related
1. Diversity: A list of n lightpaths (indicated by their IDs) from
which the present lightpath must be physically diverse in the
network. For each lightpath ID it may specified whether the
diversity desired is link, node or SRLG [1] disjoint. All the
specified lightpaths must originate from the same source OXC that
the present lightpath is being established.
6.3.4 Miscellaneous
1. Result Code: A code indicating success or failure of certain
operations. For example, a lightpath create request could result
in success or failure. This code may indicate the result as well
as the reason for failure.
2. Status: A code that indicates the status of a lightpath in the
"Lightpath Status Response" message.
6.3.5 Security-related
It is assumed that the security features provided by individual
signaling protocols (RSVP/LDP) will be used as appropriate.
6.3.6 Policy, accounting and authorization related
A container for policy-related attributes must be available in
signaling protocols (e.g., RSVP policy data object). Presently,
contract ID is recognized as a policy parameter. Other parameters
are TBD.
6.4 Contents of UNI Abstract Messages
The message contents described below may evolve based on ongoing
work, and on the development of security, policy, accounting and
other parameters.
Expires on 5/24/01 Page 11 of 16
draft-bala-mpls-optical-uni-signaling-01.txt
6.4.1 Lightpath Create Request
This message contains:
1. Source client point of attachment, IP address (mandatory)
2. Destination client point of attachment, IP address (mandatory)
3. Source client point of attachment, Port, Channel, Sub-channel
indices (optional)
4. Destination client point of attachment, Port, Channel, Sub-
channel IDs (optional)
5. Source User Group Identifier (mandatory)
6. Destination User Group Identifier (mandatory)
7. Contract ID (mandatory)
8. Framing type (mandatory)
9. Overhead termination type (mandatory)
10. Bandwidth (mandatory)
11. Directionality (optional)
12. Propagation Delay (optional)
13. Service level (optional)
14. Diversity (optional)
UNI-N may assign the channel and/or the sub-channel for the
lightpath being established and return it to the terminating UNI-C
(in the destination channel, sub-channel parameters).
6.4.2 Lightpath Create Response
This message contains:
1. Source client point of attachment, IP address (mandatory)
2. Destination client point of attachment, IP address (mandatory)
3. Source client point of attachment, Port, Channel, Sub-channel
IDs (optional)
4. Destination client point of attachment, Port, Channel, Sub-
channel IDs (optional)
5. Source User Group Identifier (mandatory)
6. Destination User Group Identifier (mandatory)
7. Lightpath ID (mandatory)
8. Result code (mandatory)
The lightpath ID is filled in by UNI-N and conveyed to both
initiating and terminating clients. In addition, UNI-N may
assign the channel and/or the sub-channel for the lightpath being
established and return it to the initiating UNI-C (in the source
logical port ID feild).
6.4.3 Lightpath Delete Request
This message contains:
1. Lightpath ID (mandatory)
Expires on 5/24/01 Page 12 of 16
draft-bala-mpls-optical-uni-signaling-01.txt
6.4.4 Lightpath Delete Response
This message contains:
1. Lightpath ID (mandatory)
2. Result Code (mandatory)
6.4.5 Lightpath Modify Request
This message contains:
1. Lightpath ID (mandatory)
2. Contract ID (mandatory)
3. Lightpath Bandwidth (optional)
4. Service Level (optional)
5. Diversity (optional)
These parameters specify the new values desired for the lightpath
identified.
6.4.6 Lightpath Modify Response
This message contains:
1. Lightpath ID (mandatory)
2. Lightpath Bandwidth (optional)
3. Service Level (optional)
4. Diversity (optional)
5. Result code (mandatory)
These parameters indicate the new values of the parameters after
the success or failure of the modificiation attempt (as indicated
in the result code)
6.4.7 Lightpath Status Enquiry
This message contains:
1. Lightpath ID (optional)
2. UNI-C ID (optional, mandatory if (1) is not present)
If the lightpath ID is not present, then the parameters of all
lightpaths owned by the UNI-C is returned by the network. Otherwise,
the status of the indicated lightpath is returned.
6.4.8 Lightpath Status Response
This message contains:
1. Status (mandatory)
2. Lightpath ID (optional)
3. Source client point of attachment, IP address (optional)
4. Destination client point of attachment, IP address (optional)
5. Source client point of attachment, Logical Port ID (optional)
Expires on 5/24/01 Page 13 of 16
draft-bala-mpls-optical-uni-signaling-01.txt
6. Destination client point of attachment, Logical Port ID
(optional)
7. Source User Group Identifier (optional)
8. Destination User Group Identifier (optional)
9. Contract ID (optional)
10. Framing type (optional)
11. Bandwidth (optional)
12. Overhead termination type (optional)
13. Directionality (optional)
14. Propagation Delay (optional)
15. Service level (optional)
16. Diversity (optional)
The status parameter indicates the lightpath status, up/non-
existant/failed/in recovery, etc. Other parameters are returned if
necessary (see 6.4.7)
6.4.9 Notification
This message contains:
1. Lightpath ID (mandatory)
2. Status (mandatory)
6.4.10 Address Query
This message contains:
1. Client-network address type (mandatory)
2. Client-network address value (mandatory)
3. Client user group ID (mandatory).
7. Summary and Conclusion
This draft described the domain services model and the signaling
requirements at the client-optical interface, called the UNI. The
objective of this draft are two-fold: to guide the adaptation of
RSVP-TE/LDP for UNI signaling and to harmonize the signaling mechanisms
and parameter encoding under UNI signaling with GMPLS signaling [5].
This draft reflects the ongoing work at the OIF, and the contents are
expected to evolve as work progresses on UNI signaling.
8. References
1. B. Rajagopalan, J. Luciani, D. Awduche, B. Jamoussi and B. Cain,
"IP over Optical Networks: A Framework", draft-many-ip-optical-
framework-02.txt, Work in Progress, November, 2000.
2. K. Arvind, et. al, "Optical Domain Services Interconnect (ODSI)
Signaling Control Specification, Version 1.4.5,ö November, 2000.
Expires on 5/24/01 Page 14 of 16
draft-bala-mpls-optical-uni-signaling-01.txt
3. D. Pendarakis, B. Rajagopalan and D. Saha, "Routing Information
Exchange in Optical Networks," draft-prs-optical-routing-01.ps,
Internet Draft, Work in Progress, November, 2000.
4. B. Fox and B. Gleeson, "VPN Identifiers," RFC 2685.
5. P. Ashwood-Smith et. al, "Generalized MPLS - Signaling
Functional Description", draft-ietf-mpls-generalized-signaling-
00.txt, Internet Draft, Work in Progress, November, 2000.
6. J. P. Lang, et al., "Link Management Protocol," draft-ietf-mpls-
lmp-01.txt, Internet Draft, Work in progress, November, 2000.
9. Authors' Addresses
Osama S. Aboul-Magd Olga Aparicio
Nortel Networks Cable & Wireless Global
P.O. Box 3511, Station ôCö 11700 Plaza America Dr
Ottawa, Ontario, Canada Reston, VA 20191
K1Y û 4H7 Ph: 703-292-2022
{osama@nortelnetworks.com} {olga.aparicio@cwusa.com}
Rick Barry Greg Bernstein
Sycamore Networks Ciena Corporation
10 Elizabeth Drive 10201 Bubb Road
Chelmsford, MA 01824 Cupertino, CA 95014
{Rick.Barry@Sycamorenet.Com} {gregb@ciena.com}
Raj Jain Liangyu Jia, Rajiv Dulepet
Nayna Networks, Inc. ONI Systems Corp.
157 Topaz St. 166 Baypointe Parkway
Milpitas, CA 95035 San Jose, CA 95134
Phone: 408-956-8000 X309 Tel. 408-965-2743
{raj@nayna.com} {ljia, rdulepet}@oni.com
Monica A. Lazer Dimitrios Pendarakis
AT&T Bala Rajagopalan
900 Rt. 202/206 N Tellium, Inc
Bedminster NJ 07921 2 Crescent Place
Phone: 908 234 8462 Ocean Port, NJ 07757
{mlazer@att.com} {dpendarakis,
braja}@tellium.com}
Robert Rennison Yangguang Xu
Laurel Networks Lucent Technologies
2607 Nicholson Road 21-2A41, 1600 Osgood St.
Sewickley, PA 15143 N. Andover, MA 01845
Tel: +1 (724) 933 7330 Tel: (978) 960 6105
{robren@laurelnetworks.com} { x uyg@lucent.com}
Expires on 5/24/01 Page 15 of 16
draft-bala-mpls-optical-uni-signaling-01.txt
Yong Xue Jennifer Yates
UUNET/WorldCom AT&T Labs
Ashburn, Virginia 180 Park Avenue
(703)-886-5358 Florham Park, NJ, 07932
{yxue@uu.net} {jyates@research.att.com}
John Z. Yu Zhensheng Zhang
Zaffire, Inc Sorrento Networks
2630 Orchard Parkway 9990 Mesa Rim Road
San Jose, CA 95134 San Diego, CA 92121
Ph:(408) 894-7364 tel: 858-646-7195
{jzyu@zaffire.com} {zzhang@sorrentonet.com}
Expires on 5/24/01 Page 16 of 16
