One document matched: draft-awduche-ipo-gmpls-signaling-applicability-00.txt
IPO Working Group Daniel Awduche
Internet Draft Adrian Farrel
Expiration Date: January 2003 Movaz Networks
GMPLS Signaling Applicability Statement
draft-awduche-ipo-gmpls-signaling-applicability-00.txt
1. Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026, except that the right to
produce derivative works is not granted.
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.
2. Abstract
This memo describes the applicability of GMPLS signaling to IP over
Optical (IPO) networks. The underlying premise behind GMPLS
signaling for IPO networks is discussed and pertinent limitations
are highlighted. Throughout this discussion, GMPLS-RSVP (RSVP-TE
with GMPLS extensions) will be used to exemplify the class of
protocols under consideration. This memo also describes the subsets
of GMPLS signaling message exchanges that are needed to support
connection management between optical switches, and between IP/MPLS
routers and optical switches in IP over Optical networks.
3. Summary for Sub-IP Area
3.1 Summary
This document describes the applicability of GMPLS signaling to IP
over Optical Networks.
3.2 Where does it fit in the Picture of the Sub-IP Work
This work fits in the IPO Working Group.
Awduche and Farrel [Page 1]
draft-awduche-ipo-gmpls-signaling-applicability-00.txt July 2002
3.3 Why is it Targeted at this WG
This is one of chartered deliverables of the IPO working group.
3.4 Justification
The WG should consider this document because it describes how the
existing GMPLS signaling protocols can be used in IP over Optical
networks. This information is especially useful to the IETF
community because it delineates the subset of GMPLS signaling
functionality that are useful in IPO networks.
4. Introduction
This memo describes the applicability of GMPLS signaling protocols
to connection management in IP over Optical (IPO) networks. The
basic function of the GMPLS signaling protocols is to setup,
maintain, and teardown connection services in different types of
transport networks. This memo relates only to the applicability of
the GMPLS signaling capabilities in IPO networks. The applicability
of GMPLS routing protocols to IPO networks are covered in a
separate document.
The term IP over Optical networks generally refers to optical
transport networks that posses one or more of the following two
main characteristics: (1) They are used to preponderantly transport
IP traffic and (2) they employ IP (e.g. GMPLS) protocols in their
control plane. An optical network utilizing GMPLS in its control
plane may also transport other types of digital clients other than
IP traffic.
This memo is concerned specifically with optical networks that
utilize GMPLS signaling protocols in their control plane,
irrespective of the type of digital clients and payloads carried in
their transport plane. The definition of IPO networks, for the
purpose of this applicability statement, encompasses the OCh layer
of the ITU-T Optical Transport Networks (OTN) described in [8],
especially when such networks utilize GMPLS protocols in their
control planes.
The factors that motivate the application of IP-based control plane
protocols (such as GMPLS) to optical networks were articulated in
reference [5].
Awduche and Farrel [Page 2]
draft-awduche-ipo-gmpls-signaling-applicability-00.txt July 2002
5. Overview of GMPLS Signaling
GMPLS signaling protocols are general purpose control plane
protocols supporting signaling transactions in different types of
switched transport networks with different switching
technologies. The GMPLS signaling protocols are derived from the
corresponding IETF MPLS signaling protocols, (e.g., RSVP-TE [4])
through a process of extension and generalization. The GMPLS
signaling protocols employ the same protocol machinery as the
underlying protocols from which they were derived, but include
additional protocol features to support signaling capabilities in
a multitude of switched transport networks.
The main aspects of GMPLS signaling are documented in a number of
IETF memos [1,2,3,6,7]. There are two broad classes of GMPLS
signaling protocols that are being standardized by the IETF: (1)
those based on RSVP-TE and (2) those based on CR-LDP. Both classes
of protocols perform similar functions and either of the two can be
used to fulfill the necessary signaling transactions in a
particular context. However, recent surveys conducted within the
IETF suggest that GMPLS signaling protocols derived from RSVP-TE
are the most predominantly implemented in the industry (see
e.g. reference [10]).
It is significant to point out that the GMPLS architecture does not
mandate either of the two classes of GMPLS signaling for a
particular application. Therefore this applicability statement does
not prevent an implementation from utilizing either of the two
categories of protocols.
6. Applicability of GMPLS Signaling to IPO Networks
GMPLS is an appropriate signaling mechanism for establishing end-to
end connections in optical networks utilizing embedded software
control planes. GMPLS signaling provides the ability to perform
signaling transactions for connection setup and connection release
operations in optical networks. GMPLS does not impose restrictions
on the implementation of the data communication network (DCN) that
is used for conveying signaling messages. This means that GMPLS can
be employed in optical networks where the control channel is
implemented (1) in-band, (2) out-of-band in-fiber, (3) or out of
band and out-of-fiber.
GMPLS signaling messages provide the flexibility to control the
path traversed by a particular connection within an optical network
and to manage the allocation of resources used by the connection
along the path. Some of the major benefits derived from GMPLS
signaling in optical networks include the following, which are
consistent with the requirements stipulated in [12]:
- Rapid Circuit provisioning
- Flexibility
- Enhanced survivability
- Interoperability
Awduche and Farrel [Page 3]
draft-awduche-ipo-gmpls-signaling-applicability-00.txt July 2002
6.1 Provisioning Capabilities
One of the key benefits of GMPLS signaling in IPO networks is the
automation and expediting of the provisioning of optical
connections within the optical domain. With GMPLS signaling, it is
possible to specify the route traversed by an optical connection
(for example, using the Explicit Route Object in GMPLS-RSVP). It is
also possible to specify the bandwidth for the optical connection.
In an optical network, the labels exchanged by the GMPLS signaling
protocol equate directly to an abstract representation of the
optical resources to be used by the connection. Depending on the
characteristics of the optical domain, the labels may represent
individual wavelengths, wavebands or whole fibers. While whole
fibers may be identified using numbered or unnumbered interfaces,
the identification of ports, wavelengths and wavebands is a local
matter for resolution between adjacent nodes in the network. In the
case of wavelength routed optical networks, where the wavelength is
the basic unit of resource allocation, it might be convenient to
use a standardized convention for spectrum allocation such as the
ITU grid.
The conventional MPLS signaling protocols (e.g., the basic RSVP-TE
protocol) are based on downstream-on-demand resource allocation and
label binding. This means that in conventional MPLS signaling,
label allocation proceeds from downstream nodes to upstream
nodes. GMPLS signaling improves this scheme by supporting the
concept of "suggested label" where an upstream node can suggest a
label to a downstream. This concept is particularly useful in
optical networks for the following reasons: (1) it can help to
decrease provisioning latency by enabling anticipatory policies
that allow optical network elements to reconfigure their switching
elements during the forward pass of the signaling messages; and (2)
in wavelength routed optical networks, it can permit wavelength
assignment by upstream nodes.
GMPLS signaling also suppports the concept of "label set" which is
another improvement over conventional MPLS signaling. The
significance of this concept in wavelength routed optical networks
is that it allows upstream nodes to restrict the set of labels,
hence wavelengths, that can be allocated by downstream nodes.
In contexts in which network edge elements are capable of
processing signals from many different devices, it may be necessary
for them to indicate the bandwidth and encoding of the traffic
associated with a particular connection, and perhaps the required
switching behavior of the optical devices. GMPLS signaling
includes extensions offering this capability.
Awduche and Farrel [Page 4]
draft-awduche-ipo-gmpls-signaling-applicability-00.txt July 2002
The principles of traffic engineering (that is performance
optimization of networks) are very important in optical networks.
In optical networks, traffic engineering is applied almost
exclusively through routing control. GMPLS signaling allows to
explicitly specify the path traversed by an optical
connection. The path itself may be computed online or offline using
an appropriate path computation mechanism which is not part of
GMPLS signaling. This facility allows to constrain routes to fully
or partially constrain the routes traversed by an optical connection.
This facility can also be used to resolve resource contention
and blocking problems, thereby optimizing optical resource
Constraints associated with optical resources may be taken into
consideration by a path computation engine when selecting the
explicit route to be traversed by an optical connection. In this
case, the path computation engine will calculate a path subject to
pertinent constraints -- together with attendant resources to
allocate on each hop, and specify these attributes in the explicit
route object that is embedded in the signaling messages. This
capability may be enhanced on a hop-by-hop basis by having each
network element provide resource availability information and
suggestions for label allocation to its neighbor.
Additionally, it may be important to constrain the choice of
optical resources (wavelengths, wavebands, or fibers) along a path.
This capability offers a number of advantages. For example, it can
be used to allow more effective assignment of switching resources
in optical networks consisting of a combination of electrical
switching elements (requiring OEO conversion) and photonic
switching elements (PXCs without OEO conversion). It can also
substantially reduce wavelength contention and resolve wavelength
conflicts in transparent sub-networks containing PXCs, where
wavelength conversion cannot be performed at some or all
nodes. Additionally, this capability can be used to reduce
connection setup latency and signaling instability in networks
containing some classes of PXCs, in which the underlying switching
technology has a non-negligible finite reconfiguration delay and
may require a finite stabilization time. The "suggested label" and
"label set" features are some of the capabilities of GMPLS
signaling that allow to constrain the choice of optical resources.
6.2 Advanced Provisioning
6.2.1 Bidirectional Light Paths
Optical connections are often required to be bidirectional. This
can be achieved by sequentially signaling two independent
unidirectional optical connections, in opposite directions, one
from each terminating endpoint. However, this approach is not very
efficient in terms of signaling overhead and connection setup
latency. This approach also makes it difficult to achieve route
symmetry, so that both optical channel trails in opposite
directions take the same physical path through the network.
Awduche and Farrel [Page 5]
draft-awduche-ipo-gmpls-signaling-applicability-00.txt July 2002
GMPLS addresses the aforementioned issue by supporting the
establishment of bidirectional optical connections using just one
round-trip signaling message transaction. The approach adopted by
GMPLS signaling has the added advantage that both directions of the
optical connection can follow the same path, achieving the desired
goal of route symmetry in optical networks. When establishing
bi-directional optical connections, resources can be independently
allocated to the two directions, and conceptually other types of
constraints can be independently imposed as well. However, in an
operational context, it is likely the two directions of a
bi-directional optical connection will be assigned similar
resources and satisfy similar constraints.
The capability to establish bi-directional optical connections does
not, however, preclude establishing uni-directional optical
connections in contexts where uni-directionality is required in IPO
networks. Clearly, this degree flexibility is very advantageous as
the requirements imposed on optical networks will evolve and change
over time.
6.2.2 Signaling Setup Time
Many optical devices have high stabilization times. GMPLS allows a
node to pipeline signaling and device programming such that it can
suggest to its adjacent nodes which optical resources should be
used and proceed to program and reconfigure those resources before
the signaling exchange with its neighbor has completed. In the
worst case the node must provision new resources when the signaling
completes, especially if the suggested resources to be allocated
are declined by the downstream node.
6.2.3 Alarm-Free Setup and Teardown (Alarm Suppression)
Many optical networks report alarms if a service is provisioned but
no signal is present (such as loss of signal and loss of light
alarms). For example, if an optical connection is provisioned, but
a laser somewhere along the path is not turned on in a timely
fashion, an alarm may be raised. This situation can also occur
during connection reconfiguration, when the path traversed by an
existing connection is altered.
For a variety of reasons, it is often desirable to suppress alarms
during optical connection setup, reconfiguration, and teardown.
During these times it is reasonable to expect that lasers may be
turned on or off sequentially, and it is not necessary to raise
certain types of alarms, especially alarms suggesting failure
within the network.
Awduche and Farrel [Page 6]
draft-awduche-ipo-gmpls-signaling-applicability-00.txt July 2002
GMPLS offers a mechanism to indicate that a connection setup is in
progress. When such an indication is present, an optical device
may suppress certain types of alarms during the signaling
transactions. Once the optical connection has been established,
GMPLS can be used to signal that alarms should be enabled.
Similarly, GMPLS can be used to indicate that connection teardown
is in process so that optical devises can suppress pertinent
alarms during the teardown process.
6.3 Survivability Features
Survivability is a critical consideration in IPO networks. Within
the optical domain, there is generally a requirement for
flexibility in the manner in which resilience properties of optical
connections are specified and implemented. There is also a general
requirement to minimize service interruption following network
outages for services that are intended to be survivable. The
spectrum of protection/restoration capabilities that can be
associated with a particular connection can be quite large
including different protection levels (unprotected, 1+1, 1:1, 1:n,
m:n), and different types of restoration (local restoration,
end-to-end restoration, etc). In 1:1, 1:n, and m:n protection
scenarios, it may also be desirable to route "extra traffic"
(preemptable low priority traffic) over the protect resources to
increase the efficiency of asset utilization.
GMPLS signaling provides a range of capabilities to support
different types of protection/restoration mechanisms and
consequently to enable a variety of survivability options in
optical networks.
6.3.1 Connection Specific Survivability
A key requirement for the development of signaling protocols for
the optical domain in IPO networks is the need for features to
support intelligent fault management, as noted earlier.
There are four major steps involved in fault management: (1) fault
detection, (2) fault localization, (3) fault notification, and (4)
fault recovery.
Fault detection and fault localization in optical networks are not
covered by GMPLS signaling. These aspects are the responsibility
of the hardware, the transport plane, and link management protocols
(such as LMP [11]).
One of the major attributes of optical networks is that nodes
downstream of faults are the ones most likely to detect the fault
(such as loss of signal and loss of light problems). Therefore,
there is a requirements to notify nodes upstream of the fault so
they can initiate recovery actions. In the case of 1:1 and general
m:n protection schemes, it is also important to coordinate the
actions of the originating node and destination node for a
connection so that they can both switch to the pre-establish
protect path.
Awduche and Farrel [Page 7]
draft-awduche-ipo-gmpls-signaling-applicability-00.txt July 2002
GMPLS signaling protocols include fault notification mechanisms for
reporting errors across the network, from the nodes that detect the
faults to the endpoints (originating and destination nodes) of the
connection. Furthermore, these fault notification mechanisms are
defined to traverse the route of the connection, so that each node
along the path will be informed of the anomaly and can take
appropriate remedial action to rectify the problem or initiate
recovery actions to restore affected traffic. The fault
notification messages can also be targeted to specific nodes using
an appropriate encapsulation.
However, where the location of the repair points are predetermined
and known, this method of propagating fault notifications can be
slow. It is to be noted that GMPLS-RSVP specifically includes a
method that allows repair points to advertise their existence
during connection setup, or later when the connection is
modified. This capability allows fault notifications to be sent
directly to these repair points, expediting the process of
notification and consequently reducing the time to recover from
failures.
Fault repair (hence service restoration) may be accomplished by
signaling new optical connections after a fault notification
message is received (in the case of restoration), or by switching
traffic to pre-established protection paths (in the case of
protection). Some solutions may require coordination with other
nodes in the network during (or before and/or after) the recovery
of affected traffic to alternate paths (e.g., some hardware
solutions for 1+1 and 1:1 protection, bidirectional optical
connections, removal of extra traffic, etc). GMPLS-RSVP (but not
GMPLS-CR-LDP) allows such nodes to advertise their existence during
optical connection setup or later during modification operations
associated with connection reconfiguration, so that they can also
be recipients of fault notification messages which are sent to
them directly.
6.3.2 Decoupling of Control and Transport Planes
In IPO networks, it is an important operational requirement on the
part of carriers to decouple the Control plane from the Transport
plane within the optical domain, so that faults occurring within
the control plane will not affect existing services within the
optical transport plane.
In many optical networks there is no facility for in-band control
signaling since that would require both GMPLS signal and bearer
traffic termination at each node. Some implementations of optical
networks may offer in-fiber but out-of-band solutions where a
particular wavelength is dedicated to function as a control
channel. Other alternatives include an out-of-fiber control
channel that exists in parallel with the fiber carrying bearer
traffic, and a control channel that is routed separately and
independently through an external IP network.
Awduche and Farrel [Page 8]
draft-awduche-ipo-gmpls-signaling-applicability-00.txt July 2002
There are two important implications of the scenarios mentioned
above. One is the concept that failures in the control does not
necessarily imply of the transport plane. Hence, unlike
conventional IP/MPLS networks, failure of the transport plane
cannot be inferred from failure of the control plane. The second
important implication is that switching and reconfiguration
activities in the transport plane should not be initiated by
control plane failures.
GMPLS addresses this important operational issue by decoupling the
path of the GMPLS signaling message (i.e., the signaling data
communications network) from that of the bearer traffic transported
by the transport plane (unlike in conventional IP/MPLS networks
where the two are closely coupled). This decoupling of the control
and bearer channels implies that any of the in-band or out-of-band
control channel solutions may be used for GMPLS based optical
connection management. In particular, the use of IP encapsulation
by GMPLS signaling allows control packets to be routed through
distinct networks that may include other GMPLS-capable nodes that
must not examine these control packets in order to propagate them
appropriately.
This decoupling allows the transport plane to be immune to control
plane failures, whether these are hardware or software related, so
that existing optical connections are not interrupted by failures
occurring within the control plane.
With the decoupling of the control plane and transport plane,
failure detection associated with transport bearer services is no
longer the responsibility of the control plane. Rather, fault
detection and fault localization are the responsibility of the
hardware and the link management protocols (such as LMP [11]) in
the network. When such faults are detected using appropriate
mechanisms within the transport plane or using LMP, they can be
propagated to the control plane so that the control plane can
initiate failure notification actions to pertinent nodes within the
network.
Because failures can occur within the control independent of the
transport plane, it is now the responsibility of the control plane
to recover its state (to match that of the transport plane) when
control plane connectivity is recovered after a failure.
GMPLS-RSVP includes a graceful restart procedure that allows
network nodes to re-learn their state from neighbors on recovery. A
similar process is being developed for CR-LDP and is likely to
become available for GMPLS-CR-LDP.
Awduche and Farrel [Page 9]
draft-awduche-ipo-gmpls-signaling-applicability-00.txt July 2002
6.3.3 Reliable Message Delivery
Reliable message delivery is an important part of dependable and
expeditious connection setup, reconfiguration, and teardown. GMPLS
includes facilities to ensure prompt and reliable delivery of
signaling messages.
GMPLS-CR-LDP achieves this by using a reliable transport (TCP).
GMPLS-RSVP achieves the same function by applying Message Ids to all
control messages and retrying the messages until they are
acknowledged.
6.4 Architectural Considerations
The IPO framework document [9] specifies different architectural
alternatives for deployment of IP over Optical networks. The
architectural alternatives specifically concern the interconnection
models between control entities on IP/MPLS routers and control
entities on optical transport network elements, especially when the
IP and optical domains both utilize GMPLS control plane protocols.
GMPLS-RSVP can be used as a signaling protocol between a client
(e.g. IP/MPLS router) and an optical transport network in an
overlay interconnection model.
GMPLS-RSVP can also be used as a signaling protocol between optical
network elements across an interior NNI (I-NNI), and as a signaling
protocol between subnetworks across an E-NNI (Exterior NNI)
interface.
6.5 Deployment Considerations
Several distinct deployment scenarios for GMPLS signaling in IPO
networks can be identified. These include:
- Deployment within an optical subnetwork with no signaling
interactions with entities outside of the network.
- Deployment within a subnetwork with signaling interactions with
entities across the subnetwork where all subnetworks belong to the
same administrative entity.
- Deployment across networks where the networks belong to different
administrative entities. In this case, special care should be
given to security considerations.
In the case of deployments supporting signaling transactions across
networks or subnetworks, the network elements performing the
signaling transactions may utilize similar switching technologies
or different switching technologies.
Awduche and Farrel [Page 10]
draft-awduche-ipo-gmpls-signaling-applicability-00.txt July 2002
6.5.1 Restrictions
There are certain restrictions that may limit deployment of the
existing class of GMPLS signaling protocols in some IPO operational
contexts. In the following paragraph, we highlight some of the
operational scenarios in which certain restrictions may apply.
- Signaling protocol transactions across trust domains: When GMPLS
signaling is required to traverse administrative domain
boundaries it may be necessary to take security issues into
considerations. These security implications across trust domains
are not adequately covered by the existing protocol machinery.
7. Security Considerations
The security considerations relating to the GMPLS signaling
protocols are documented in the pertinent IETF protocol specific
documents. This applicability statement does not introduce new
security issues. It should be pointed out, however, that special
precaution must be taken to ensure that unauthorized entities cannot
successfully initiate or execute GMPLS signaling protocol
transactions in IPO networks.
8. References
8.1 Normative References
[1] L. Berger, et al, "Generalized MPLS - Signaling Functional
Description," Internet Draft, Work in Progress, 2002.
[2] L. Berger, et al, "Generalized MPLS Signaling - RSVP-TE
Extensions," Internet Draft, Work in Progress, 2002.
[3] P. Ashwood-Smith, et al, "Generalized MPLS Signaling - CR-LDP
Extensions," Internet Draft, Work in Progress, 2002.
[4] D. Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP Tunnels",
RFC 3209, December 2001.
[5] D. Awduche and Y. Rekhter, "Multiprotocol Lambda Switching," IEEE
Communications Magazine, June 2001.
8.2 Informative References
[6] E. Mannie, et al, "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture," Internet Draft, Work in Progress, 2002.
[7] D. Papadimitriou, "Generalized MPLS Signalling Extensions for
G.709 Optical Transport Networks Control," Internet Draft, Work
in Progress, 2002.
[8] ITU-T Recommendation G.821: "Optical Transport Network
Architecture"
Awduche and Farrel [Page 11]
draft-awduche-ipo-gmpls-signaling-applicability-00.txt July 2002
[9] B. Rajagopalan, et al, "IP over Optical Networks: a Framework,"
Internet Draft, Work in Progress, 2002.
[10] L. Berger and Y. Rekhter, "Generalized MPLS Signaling -
Implementation Survey," Internet Draft, Work In Progress, 2002.
[11] J. Lang, et al, "Link Management Protocol (LMP)," Internet
Draft, Work In Progress, 2002.
[12] Xue, et al, "Carrier Optical Services Requirements," Internet
Draft, Work in Progress, 2002.
9. Author Address
Daniel Awduche
Movaz Networks
One Technology Parkway South
Norcross, GA 30092
Phone: 703-298-5291
Email: awduche@movaz.com
Adrian Farrel
Movaz Networks
7926 Jones Branch Drive, Suite 615
McLean VA, 22102
Phone: 703-847-1867
Email: afarrel@movaz.com
11. 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.
Awduche and Farrel [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-23 17:39:36 |