One document matched: draft-mcadams-lightpath-attributes-00.txt
INTERNET DRAFT Larry McAdams
Expires: September 2000 Cisco Systems
<draft-mcadams-lightpath-attributes-00.txt>
Jennifer Yates
AT&T Labs - Research
Lightpath attributes and related service definitions
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.
Abstract
This document specifies the attributes and related service
definitions that may be associated with lightpaths in an optical
network. The document is currently being developed within the
Optical Internetworking Forum (OIF) and is being presented to the
IETF for informational purposes.
1. Introduction
The goal of this document is to specify lightpath attributes and
their use in service definition. This draft has been created within
the Optical Internetworking Forum (OIF) and submitted to the IETF as
an informational draft. As such, the document uses OIF terminology,
in particular, the draft refers to User to Network Interfaces (UNIs)
and Network to Network Interfaces (NNIs). This terminology is not
consistent with IETF terminology, and is in no way meant to imply a
particular network architecture.
McAdams, Yates [Page 1]
draft-mcadams-lightpath-attributes-00.txt March 2000
The OIFÆs generic requirements for the Optical Internetwork [1]
specify that a number of different types of clients must be
supported; that rapid provisioning should be supported; that various
levels of circuit protection be provided; that some form of mesh
restoration be supported; and that a high level of manageability and
provisioning flexibility be provided for SDH/SONET framed circuits.
[1] defines the UNI as the interface between the optical network and
a "client" to the optical network. It is required that the UNI be
provisionable to support different types of services, protection
levels, etc.; that a signaling method be provided between the client
and the UNI that might be implemented in a number of ways (in-band,
out-of-band, may or may not use SONET overhead bytes); that not all
circuit types will support duplex in-band signaling; and that the UNI
shall be specified so as to allow failure detection and localization
(in or out of the Optical Network) and notification of the failure to
the appropriate network management entities, and also continual
verification of the integrity of the circuit.
Adopting a unified protocol across both the optical network and its
clients fundamentally enhances the flexibility of the control plane.
Now, depending on the nature of the network and the service offered,
both a client-server or overlay model (i.e. UNI) and a peer-to-peer
model is possible (i.e. NNI). In some cases, the NNI may be simply
viewed as an extension of the UNI. This is an issue outside the
scope of this document.
2. Lightpath services
The optical network is primarily offering high bandwidth connectivity
in the form of lightpaths, where a lightpath is defined to be a fixed
bandwidth connection between two network elements, such as IP routers
or ATM switches, established via the optical network. The behaviors
of the lightpaths are defined by their lightpath attributes.
The definition of an atomic lightpath request needs to be discussed.
In particular, whether the atomic lightpath request is for a single
connection, or for multiple lightpaths, needs consideration. The
simplest approach is to define the atomic lightpath request to be for
a single lightpath. However, more flexibility might be achieved
using a more complicated definition, in which multiple lightpaths may
be simultaneously requested.
3. Lightpath operations
The fundamental actions or operations related to a lightpath are:
- request for a new lightpath
- disconnection or teardown of an established lightpath
- lightpath query (i.e. obtain current status information re:
lightpath)
- lightpath attribute change (i.e. change a parameter regarding an
established lightpath û e.g. restoration requirements).
McAdams, Yates Informational - Expires September 2000 [Page 2]
draft-mcadams-lightpath-attributes-00.txt March 2000
4. Lightpath attributes
A lightpath request, query, disconnect or attribute change has
associated attributes. The following is a list of the attributes
associated with a lightpath.
It is envisioned that these attributes will be negotiated over the
signaling channel between the client and the network. Many of the
attributes are denoted as being required attributes, meaning that
their definition is essential for the control plane operation.
However, other attributes are optional. In some cases, not all of
the attributes will be available, depending on the services offered
and the equipment available. However, the UNI specification should
not preclude any attribute.
Connection-related attributes
The first group of attributes are important in the connection
establishment process and in ongoing capacity management and
maintenance activities.
Although these connection-related attributes are different and in
many ways independent of the lightpath attributes used to describe
the behaviors, they are included here because they are needed and the
authors were not aware of their inclusion in any other relevant
documents. If they are under discussion in other more appropriate
documents they may be removed from this document and transferred to
such related documents as appropriate.
- globally unique end-to-end lightpath identifier: an identifier for
the lightpath. This identifier may be assigned by either the
client, or by the network. This is a required attribute in the
sense that it must be known or derivable by the network.
- client identifier: an identifier by which we can refer to the
business entity which "owns" the lightpath. It could also identify
a specific "virtual optical network" (analogous to IP VPNÆs) if
the need arose. This is important for connection acceptance,
billing, etc. It appears to differ from the information
obtainable by end system discovery, which is focused on
topological information. In some cases it may be derivable from
port information. This is a required attribute in the sense that
it must be known or derivable by the network.
- security object: required for authentication, but could be closely
related to the client identifier. The necessity and details of
this needs further study.
- desired availability period: the date/time when the lightpath is
desired to be in service, and the earliest and latest date/time
when the lightpath will be disconnected. The disconnect
information is needed for capacity management; it might also be a
factor in determining charges. It could be set to infinity. The
inclusion of this attribute within the optical network as opposed
McAdams, Yates Informational - Expires September 2000 [Page 3]
draft-mcadams-lightpath-attributes-00.txt March 2000
to a higher layer management system should be further
investigated.
- destination address: the address of the destination to which the
lightpath is to be established. It is proposed that this address
be an IP address. However, it is unclear whether additional
addressing schemes need to be understood by the optical network to
handle non-IP aware equipment, such as ATM switches. Should the
optical network understand multiple higher layer addressing
schemes, or should the non-IP aware boxes (e.g. ATM switches) be
assigned IP addresses by which they are referred to in the optical
network? These IP addresses could be associated with the ports to
which the clients are attached to the optical network. This is a
required attribute.
- destination port index: if individual ports are not given unique
addresses, then a port index is required to identify them. The
destination port index used by a lightpath may be assigned by
either the client, or by the network. This is a required
attribute.
- destination sub-port index: when the network or end system allows
multiplexing or switching at a finer granularity below the port
level then the sub-port index is used to refer to specific
channels below the port level. In future, more highly integrated
systems there may be a need for additional levels of sub-port
indexes. The destination sub-port index may be assigned by either
the client or the network. This is an optional attribute.
- source address: the address from which the lightpath is to be
established. This is a required attribute in the sense that it
must be known or derivable by the network.
- source port index: similar to destination port index. The source
port index may be assigned by either the client or the network.
This is a required attribute in the sense that it must be known or
derivable by the network.
- source sub-port index: similar to destination sub-port index. The
source sub-port index may be assigned by either the client or the
network. This is an optional attribute.
Physical attributes
The next group of attributes relate to the physical and transmission
characteristics of a lightpath.
- framing type and use: the line protocol carried on the lightpath.
Examples of such line protocols include SONET/SDH and Ethernet
(GbE and 10GbE). This parameter may not be required in an
optically transparent network. The proposed digital wrapper may
allow some simplification of this attribute to the extent that it
is used to encapsulate line protocols, but it cannot be assumed to
be ubiquitous. This is a required attribute.
McAdams, Yates Informational - Expires September 2000 [Page 4]
draft-mcadams-lightpath-attributes-00.txt March 2000
Other attributes need to be associated with specific line
protocols. For example, transparency and drop side protection
attributes need to be associated with lightpaths established using
SONET/SDH framing.
transparency: Because of its ubiquity, SONET/SDH framing is
particularly important. Three modes of operation that could be
supported at the UNI are identified in [2]:
Transparent: All SONET/SDH overheads would be transported
unchanged. This would avoid interoperability problems with
client signals using proprietary features or management
techniques.
Regenerator Section (SONET Section) Termination: AIS could be
inserted, and a segment of a SDH MS Shared Protection Ring
(SONET BLSR) could be transported. Protection would be limited
to 1+1.
Multiplex Section (SONET Line) and Regenerator Section
Termination: The tributaries within a channelized facility could
be routed separately, and the K1/K2 bytes would be available for
use within the Optical Layer. M:N Linear Automatic Protection
Switching could also be supported.
Performance monitoring and fault handling for each of these
options needs further study. This is a required attribute.
drop side protection: This refers to protection between the client
network element and the optical network. In the case of co-
location, the choices would seem to be 0:1(unprotected), 1:N, M:N
and 1+1. The non-colocated case needs further study. This is a
required attribute.
Similar attributes will need to be investigated / defined for
other framing types.
- capacity: bandwidth associated with the lightpath. For example, a
lightpath used to transport SONET encoded signals may be
configured to have OC-N capacity, or STS-M capacity. STS-1
granularity is suggested for SONET encoded signals, although this
does not imply that a vendor has to implement such a granularity.
This parameter may not be required in an optically transparent
network. Asymmetric capacity might be provided by combining bi-
directional and uni-directional capacity assignments; however this
requires further study. This is a required attribute.
- directionality: lightpaths may be either uni-directional or bi-
directional. This is a required attribute.
- priority and pre-emptability: this multi-level attribute determines
a lightpathÆs treatment during restoration and provisioning
events. This attribute would specify whether or not the resources
used by a lightpath are reusable by other lightpaths in the event
that there is insufficient capacity to handle a failure or the
provisioning of a new lightpath with a higher priority. A simple,
single level form of this attribute is required, while more
McAdams, Yates Informational - Expires September 2000 [Page 5]
draft-mcadams-lightpath-attributes-00.txt March 2000
elaborate multi-level forms are optional and may require further
study.
- protection and restoration: numerous possible definitions of
protection levels exist. The simplest is to have a binary decision
as to whether the lightpath is restored or not. At a finer
granularity, different types of restoration can be specified.
These need to be defined in terms of sub-attributes, such as:
1. restoration time,
2. what restoration capacity would be used (dedicated or shared,
for example),
3. what restoration method should be used (e.g. mesh or BLSR, for
example),
4. what failures are targeted (single link, single node, two
links, ...), and
5. reversion strategy - does the lightpath get restored to its
original route? An "optimal" available route? When?
It is preferable that the definition of this attribute be
functional (e.g., 100 mSec restoration time) rather than solution-
specific (e.g., SONET BLSR). However, the above definition
provides the ability for solution-specific restoration
requirements. Maximum flexibility should be left for vendor and
network operator innovation without requiring a standards change.
A simple form of this attribute is required, while more elaborate
forms will require further study.
Routing attributes
- relationships between lightpaths: various relationships may be
defined between lightpaths. For example, a client may request
that multiple lightpaths be diversely routed, that multiple
lightpaths be routed along the same physical route, that multiple
lightpaths be bundled together and treated as a single entity with
a common set of attributes, or that a given lightpath be routed on
the same route as an existing lightpath.
Two lightpaths are diverse if they have no Shared Risk Link Groups
in common (See [3] for more on Shared Risk Link Groups.) Diverse
routing is frequently a requirement of sophisticated enterprise
networks whose availability objectives may require that no single
failure isolate a node or disconnect the network, for example.
The diversity requirement for such a network is best expressed by
a matrix, with element a{j,k} specifying whether lightpaths j and
k must be diverse.
This attribute requires further study. In particular, the
definition of how multiple lightpaths may be bundled together
requires further work.
- specified routing: client specification for specific physical
routing of a lightpath. This routing may be specified in terms of
specific links or nodes which must/must not be traversed.
McAdams, Yates Informational - Expires September 2000 [Page 6]
draft-mcadams-lightpath-attributes-00.txt March 2000
Constraints such as the maximum delay or number of hops should
also be supported.
The delay is of particular importance. There are a number of ways
to characterize delay. A simple metric is the total round trip
delay; however it may be desirable to create a more detailed
description of the temporal behavior. For example, in some
cases, the differential delay between the incoming and the
outgoing directions of the lightpath may be important. Finally,
the change in delay caused by a protection event may also be
important. In other words, it may be desirable to not only
establish the temporal behavior of the primary lightpath, but also
the temporal behavior of the lightpath after it has been restored,
so that the delay is bounded on both the primary and restoration
routes. Delay along a lightpath will be directly proportional to
the route mileage of the lightpath, so it may be appropriate to
formulate this constraint in mileage terms.
This attribute requires further study.
- client constraints: client constraints may have to be propagated
across the UNI - particularly in all-optical networks without
wavelength conversion available between the client and the
network. In particular, information may have to be conveyed
regarding the set of wavelengths accessible from the client and
whether the client can re-tune its wavelengths in the face of a
failure within the network. This parameter requires further
investigation.
5. Summary
This document specifies lightpath attributes and their use in service
definition.
6. References
[1] R. Bary, "Proposed Architecture Working Group Requirements
Document," OIF contibution OIF2000.007.
[2] J. Berthold, "Optical Internetworking Requirements for SDH Framed
UNIs," OIF contribution OIF1999.161.
[3] S. Chaudhuri, G. Hjßlmt²sson and J. Yates, " Control of Lightpaths
in an Optical Network," IETF Internet Draft.
7. Author's addresses
Larry McAdams
Cisco Systems Inc.
170 West Tasman Drive
San Jose, CA 95134-1706, USA
lmcadams@cisco.com
+1 408 525 4628
McAdams, Yates Informational - Expires September 2000 [Page 7]
draft-mcadams-lightpath-attributes-00.txt March 2000
Jennifer Yates
AT&T Labs - Research
180 Park Avenue, Room B159
Florham Park, NJ 07932, USA
jyates@research.att.com
+1 973 360 7036
McAdams, Yates Informational - Expires September 2000 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-23 23:00:11 |