One document matched: draft-lin-ccamp-gmpls-ason-rqts-00.txt
CCAMP Working Group D. Papadimitriou
Internet Draft Alcatel
Document: draft-lin-ccamp-gmpls-ason-rqts-00.txt
Z. Lin
Lucent
O. Aboul-Magd
Nortel
D. Pendarakis
Tellium
Expiration Date: February 2003 August 2002
Requirements for Generalized MPLS (GMPLS) Usage and Extensions
For Automatically Switched Optical Network (ASON)
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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
The GMPLS suite of protocol specifications has been defined to
provide support for different technologies as well as different
applications. These include support for requesting TDM connections
based on SDH/SONET as well as Optical Transport Networks (OTNs).
Lin 1
ASON Requirements for GMPLS August 2002
This document concentrates on the signaling aspects of the GMPLS
suite of protocols. It identifies functions to be covered by these
signaling protocols to support the capabilities of an ASON network.
This document provides additional requirements on the GMPLS signaling
protocols to support the ASON functionality.
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 [2].
3. Introduction
The GMPLS suite of protocol specifications has been defined to
provide support for different technologies as well as different
applications. These include support for requesting TDM connections
based on SDH/SONET as well as Optical Transport Networks (OTNs), and
for setting up connections with monitoring capabilities. In addition,
there are certain capabilities that are needed to support
applications as described in ITU-T ASTN (Automatically Switched
Transport Networks) Requirements [G807], ASON (Automatically Switched
Optical Networks) Architecture and Requirements [G8080], Distributed
Connection Management [G7713]. These include generic capabilities
such as call and connection separation and more specific capabilities
such as support of soft permanent connections. More details about
these requirements may also be found in [IPO-RQTS] and [ASON-RQTS].
This document concentrates on the signaling aspects of the GMPLS
suite of protocols. It discusses functional requirements that would
lead to additional extensions to GMPLS to support the capabilities as
specified in the above referenced documents.
3.1 Relationship of ASON to GMPLS
The Automatic Switched Optical Network (ASON) architecture (as
specified by various ITU-T Recommendations) describes the application
of an automated control plane for supporting connection management
services for the transport plane. The ASON architecture is described
based on the functions supported, and the interactions of various
functions with each other. These include specification of the call
and connection controllers, as well as link resource managers (for a
Lin 2
ASON Requirements for GMPLS August 2002
detailed description see [G8080]). The ASON control plane
specification is meant to be applicable to different transport
technologies (e.g., SDH/SONET, OTN) in various networking
environments (e.g., inter-carrier, intra-carrier), supporting
different types of interfaces (e.g., Interior NNI (I-NNI), Exterior
NNI (E-NNI), UNI). The ASTN meta-modeling framework and the ASON
architectural model provided in ITU-T may be used as a foundation for
developing and/or extending the protocols to support specific
functions of ASON. A full description of the ASON terms and
relationship between ASON model and GMPLS protocol suite may be found
in [IPO-RQTS].
Automation of the connection management services may be realized in a
number of ways, including the use of the suite of GMPLS protocols to
support distributed connection management.
3.2 Applicability of GMPLS to ASON
Most of the applicability statements regarding how the GMPLS suite of
protocols may be applied to the ASON architecture can be found in
[IPO-RQTS], which includes a summary of the ASON functions as well as
a detailed discussion of the applicability of the GMPLS protocol
suite.
Note: Because ITU-T is currently specifying additional capabilities
to the ASON architecture, additional extensions may be needed in the
future. This is however beyond the scope of this document.
3.3 Soft Permanent Connection (SPC): A Synopsis
An SPC is a combination of a permanent connection at the source user-
to-network side, a permanent connection at the destination user-to-
network side, and a switched connection within the network.
Establishment of the switched connection within the network is
typically initiated by an EMS or NMS, which communicates with the
ingress node and instructs it to set-up the connection using the
distributed signaling protocol. For the SPC, the communication method
between the EMS/NMS and the ingress node is beyond the scope of this
document.
The user end-to-end connection is thus created by associating the
incoming interface of the switched connection initiating (also
referred to as ingress node) network node with the switched
connection within the network and the outgoing interface of the
Lin 3
ASON Requirements for GMPLS August 2002
switched connection terminating (also referred to as egress node)
network node. An SPC connection is illustrated in the following
Figure, which shows user's node A connected to a provider's node B
via link #1, user's node Z connected to a provider's node Y via link
#3, and a (abstract) link #2 connecting provider's node B and node Y.
+---+ +---+ +---+ +---+
| A |--1--| B |-----2-//------| Y |--3--| Z |
+---+ +---+ +---+ +---+
In this instance, the connection on link #1 and link #3 are both
provisioned (permanent connections that may be simple links), i.e.,
they are set up by means beyond the distributed control plane. In
contrast, the connection over link #2 is set up using the distributed
control plane. Thus the SPC is composed of the concatenation of link
#1, #2 and #3.
Thus to support the capability to request a SPC connection:
- The GMPLS signaling protocol must be capable of supporting the
ability to indicate the label information used when setting up
the destination provisioned connection.
- In addition because of the multi-domain nature of ASON networks,
the GMPLS signaling protocol must also be capable of supporting
indicating the service level and diversity requested for the SPC
(see [OIF-UNI1] for a definition). In the case where a SPC may
span multiple domains in an ASON network there may also be a
need to indicate both the source and destination controllers
managing the SPC request. These may be done via the source and
destination controller addresses.
3.4 Call: A Synopsis
A call may be simply described as: "An association between endpoints
that supports an instance of a service" [G8080]. Thus a call can be
considered as a service provided to the user endpoints, where
multiple calls may exist between any two endpoints. Each call may
have multiple connections. The call concept provides an abstract
relationship between two users, where this relationship describes (or
verifies) the extent to which the users are willing to offer (or
accept) service to each other. A call therefore does not provide the
actual connectivity for transmitting user traffic, but only builds a
relationship by which future connections may be made.
Lin 4
ASON Requirements for GMPLS August 2002
A property of a call is its ability to contain multiple connections,
where each connection may be of a different type and where each
connection may exist independently of other connections within the
call, i.e., each connection is setup and released with separate
Path/Resv messages. For example, a call may contain a mix of basic
connection, virtual concatenated connections and contiguous
concatenated connections (see [GMPLS-SDHSONET] for corresponding
connection signaling extensions).
The concept of the call allows for a better flexibility in how users
set up connections and how network offers services to users. In
essence, a call allows:
- Support for virtual concatenation where each connection can
travel on different diverse paths
- allows the use of a public and private addressing space (hosts
using public space while network using only internal private
addressing space)
- Better upgrading strategy for service provider control plane
operation, where a call control (service provisioning) may be
separate from switches and connections (where the connection
control may reside)
- Verification and authentication of a call (with both network
call controller as well as destination user) prior to
connection, which may result in less wasted resources
- General treatment of multiple connections which may be
associated for the purpose of recovery; for example a pair of
primary and backup connections may belong to the same call.
Thus to support the introduction of the call concept, the GMPLS
signaling protocol must be extended to include a call identifier and
extended to include specifying the call capability.
A possible structure for the call identifier (to guarantee global
uniqueness) is to concatenate a globally unique fixed ID (e.g., may
be composed of country code, carrier code) with an operator specific
ID (where the operator specific ID may be composed of a unique access
point code û such as source LSR address û and a local identifier).
Therefore, a foreseeable structure may be <global id> + <operator
specific id>.
4. Support For Behaviors during Control Plane Failures
Various types of control plane failures may occur within an
automatically switched optical network. These failures may impact the
Lin 5
ASON Requirements for GMPLS August 2002
control plane as well as the data plane. Requirements placed on the
control plane by [G8080] and [G7713] include:
- Any control plane failure must not result in releasing an
established transport plane connection
- The management system should be allowed to override the default
behaviors of the control plane
- Upon recovery from a control plane failure, the recovered
control plane node must have the ability to recover the status
of the established transport plane connections
- Upon recovery from a control plane failure, the recovered
control plane node must have the ability to recover the
connectivity information of its neighbors
- Upon recovery from a control plane failure, connections in the
process of been established (i.e. pending connection setup
requests) may be released
- Upon recovery from a control plane failure, connections in the
process of been released must be released
5. Support For Label Usage
Labels are defined in GMPLS to provide information on the resources
used on link local basis for a particular connection. The labels may
range from specifying a particular timeslot, a particular wavelength
to a particular port/fiber. In the context of the automatic switched
optical network, the value of a label MAY not be consistently the
same across a link. For example, the figure below illustrates the
case where two GMPLS/ASON-enabled nodes (A and Z) are interconnected
across two non-GMPLS/ASON-enabled nodes (B and C), where these nodes
are all SDH/SONET nodes providing, e.g., a VC-4 service.
+-----+ +-----+
| | +---+ +---+ | |
| A |---| B |---| C |---| Z |
| | +---+ +---+ | |
+-----+ +-----+
Labels have an associated structure imposed on them for local use
based on [GMPLS-SDHSONET] and [GMPLS-OTN]. Once the local label is
exchanged with its neighboring control plane node, the structure of
the local label MAY not be significant to the neighbor node since the
association between the local and the remote label may not
necessarily be the same. This issue does not present a problem in a
simple point-to-point connections between two control plane-enabled
nodes where the timeslots are mapped 1:1 across the interface.
Lin 6
ASON Requirements for GMPLS August 2002
However, in the scope of the ASON, once a non-GMPLS capable sub-
network is introduced between these nodes (as in the above figure,
where the sub-network provides re-arrangement capability for the
timeslots) label scoping MAY become an issue.
In this context, there is an implicit assumption that the data plane
connections between the GMPLS capable edges already exist prior to
any connection request. For instance node A's outgoing VC-4's
timeslot #1 (with SUKLM label=[1,0,0,0,0]) as defined in [GMPLS-
SONETSDH]) may be mapped onto node BÆs outgoing VC-4's timeslot #6
(label=[6,0,0,0,0]) may be mapped onto node C's outgoing VC-4's
timeslot #4 (label=[4,0,0,0,0]). Thus by the time node Z receives the
request from node A with label=[1,0,0,0,0], the node Z's local label
and the timeslot no longer corresponds to the received label and
timeslot information.
As such to support the general case, the scope of the label value is
considered local to a control plane node. A label association
function can be used by the control plane node to map the received
(remote) label into a locally significant label. The information
necessary to allow mapping from received label value to a locally
significant label value may be derived in several ways:
- Via manual provisioning of the label association
- Via discovery of the label association
Either method may be used. In the case of dynamic association, this
implies that the discovery mechanism operates at the timeslot/label
level before the connection request is processed at the ingress node.
Note that in the simple case where two nodes are directly connected,
no association may be necessary (in particular, for directly
connected TDM interfaces no mapping function is required due to the
label structure (see [GMPLS-SDHSONET] and [GMPLS-OTN]). In such
instances, the label association function provides a one-to-one
mapping of the received to local label values.
6. Additional Error Cases
To support the ASON network, the following additional category of
error cases are defined:
- Errors associated with basic call and soft permanent connection
support. For example, these may include incorrect assignment of
IDs for the Call or an invalid interface ID for the soft
permanent connection.
Lin 7
ASON Requirements for GMPLS August 2002
- Errors associated with policy failure during processing of the
new call and soft permanent connection capabilities. These may
include unauthorized request for the particular capability.
- Errors associated with incorrect specification of the service
level and diversity.
7. Security Considerations
The separation of the call and connection as required for the ASON
model will introduce a new level of management hierarchy to the
connection setup. A connection cannot be established until a call
with the same call identifier value has been set up. Policy and
authentication procedures can be applied to the establishment of the
call and then can be restricted to connection establishment within
the context of a call.
8. Acknowledgements
The authors would like to thank Jerry Ash, Greg Bernstein, Adrian
Farrel, Nic Larkin, and Lyndon Ong for their comments and
contributions to the draft.
9. References
9.1 Normative References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
[G8080] ITU-T Rec. G.8080/Y.1304, Architecture for the
Automatically Switched Optical Network (ASON), November 2001
[G7713] ITU-T Rec. G.7713/Y.1704, Distributed Call and Connection
Management (DCM), November 2001
[OIF-UNI1] OIF-UNI-01.0, User Network Interface (UNI) 1.0 Signaling
Specification
Lin 8
ASON Requirements for GMPLS August 2002
[GMPLS-SIG] P. Ashwood-Smith, Generalized MPLS - Signaling
Functional Description, draft-ietf-mpls-generalized-signaling-08.txt,
April 2002, Work in progress
[GMPLS-SDHSONET] E. Mannie and D.Papadimitriou (Editors), GMPLS
Extensions for SONET and SDH Control, draft-ietf-ccamp-gmpls-sonet-
sdh-05.txt, June 2002, Work in progress
[GMPLS-OTN] D. Papadimitriou, GMPLS Signalling Extensions for G.709
Optical Transport Networks Control, draft-ietf-ccamp-gmpls-g709-
01.txt, June 2002, Work in progress
9.2 Informative References
[G807] ITU-T Rec. G.807/Y.1301, Requirements For Automatic Switched
Transport Networks (ASTN), July 2001
[GMPLS-SDHSONETEXT] E. Mannie and D.Papadimitriou (Editors), GMPLS
Extensions to Control Non-Standard SONET and SDH Features, draft-
ietf-ccamp-gmpls-sonet-sdh-extensions-03.txt, June 2002, Work in
progress
[IPO-RQTS] O. Aboul-Magd, Automatic Switched Optical Network (ASON)
Architecture and Its Related Protocols, draft-ietf-ipo-ason-02.txt,
March 2002, Work in progress
[ASON-RQTS] Y. Xue, Carrier Optical Services Requirements, draft-
ietf-ipo-carrier-requirements-02.txt, March 2002
10. Author's Addresses
Osama Aboul-Magd
Nortel Networks
P.O. Box 3511, Station "C"
Ottawa, Ontario, Canada
K1Y-4H7
Tel: + 1 613 763 5827
Email: osama@nortelnetworks.com
Sergio Belotti
Alcatel
Via Trento 30,
I-20059 Vimercate, Italy
Email: sergio.belotti@netit.alcatel.it
Lin 9
ASON Requirements for GMPLS August 2002
Zhi-Wei Lin
Lucent
101 Crawfords Corner Road
Holmdel, NJ 07733 USA
Email: zwlin@lucent.com
Dimitri Papadimitriou
Alcatel
Francis Wellesplein 1,
B-2018 Antwerpen, Belgium
Email: Dimitri.Papadimitriou@alcatel.be
Dimitrios Pendarakis
Tellium
2 Crescent Place
Oceanport, NJ 07757-0901
Email: dpendarakis@tellium.com
Lin 10
ASON Requirements for GMPLS August 2002
Full Copyright Statement
"Copyright (C) The Internet Society (2002). 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.
Lin 11
| PAFTECH AB 2003-2026 | 2026-04-23 08:18:01 |