Network Working Group
Internet Draft
Expiration Date: September 2001
Osama Aboul-Magd (Nortel)
Daniel Awduche (Movaz Networks)
Curtis Brownmiller (Worldcom)
John Eaves (Tycom)
Rudy Hoebeke (Alcatel)
Hirokazu Ishimatsu (Japan Telecom)
Monica Lazer (AT&T)
Guangzhi Li (AT&T)
Michael Mayer (Nortel)
Ananth Nagarajan (Sprint)
Lynn Neir (Sprint)
Sandip Patel (Lucent)
Eve Varma (Lucent)
Yangguang Xu (Lucent)
Yong Xue (UUNET/WorldCom)
Jennifer Yates (AT&T)
A Framework for Generalized Multi-protocol Label Switching (GMPLS)
draft-many-ccamp-gmpls-framework-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Y. Xu, et. al. [Page 1]
draft-many-ccamp-gmpls-framework-00.txt Jan. 2002
Abstract
This document presents a framework for the GMPLS control plane. It studies
the GMPLS control plane from three different perspectives: functional
partitioning, computational layering and network partitioning. First, it
studies the functional building blocks of a generic GMPLS control plane and
illustrates that, in order to be generalized for different technologies and
their specific application environment, what each functional component could
assume, what it "should" (instead of "how") accomplish, what are the generic
procedures and possible options. Then, this document goes beyond the
functional partitioning and a single network. It illustrates the
computational network layering, network partitions and their implications to
the GMPLS control plane design, operations for the overall hybrid network. It
also covers issues associated with control plane interaction of multiple
networks, control plane integration and control plane operation models.
This document focuses on different aspects of the GMPLS control plane from
what the requirement document [CARR-REQ] and GMPLS architecture document
[GMPLS-ARCH] focused. It completes these drafts and other GMPLS related
works.
Summary for Sub-IP Area
SUMMARY:
Please see the abstract above
RELATED DOCUMENTS:
See the Reference Section
WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK:
This work fits in the Control Plane of CCAMP
WHY IS IT TARGETED AT THIS WG:
GMPLS belongs to CCAMP. Because this document presents a framework
for GMPLS, it would be logical to target this document at the CCAMP WG.
JUSTIFICATION
CCAMP charter looks for a framework document. This document is a
revision of previous work that was considered as a good fit for GMPLS
framework. The document was written by a balanced group of authors from both
service providers and carriers. It completes the requirement and architecture
documents for GMPLS control plane and provides guidance to protocol designs.
So CCAMP should consider this WG.
Y. Xu, et. al. [Page 2]
draft-many-ccamp-gmpls-framework-00.txt Jan. 2002
Table of Contents
1 Specification .........................................
2 Acronyms .............................................
3 Introduction ..........................................
4 Background ............................................
4.1 Transport Technology Overview .........................
4.2 Transport Network Control Plane Evolution and Options ..
4.3 Motivation for A GMPLS Control Plane ..................
5 GMPLS Control Plane Functions and Goals ................
6 Architectural Components of GMPLS Control Plane .......
6.1 Architectural Overview ...............................
6.2 Data Communication Network for GMPLS Control Plane ....
6.3 LSR Level Resource Discovery and Link Management .....
6.4 GMPLS Routing ........................................
6.5 GMPLS Signaling ......................................
7 GMPLS Operation Models and Control Plane Integration ..
7.1 LSP Hierarchy and the Network Layering ................
7.2 Network Partitioning and Control Plane Interfaces ....
7.3 GMPLS Control Plane Operation Models .................
8 Security Considerations ...............................
9 Acknowledgment ........................................
10 Authors' Addresses ....................................
11 References ............................................
Y. Xu, et. al. [Page 3]
draft-many-ccamp-gmpls-framework-00.txt Jan. 2002
1. Specification
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. Acronyms
ASTN : Automatic Switched Transport Network
OTN : Optical Transport Network
LSR : Label Switched Router
(In this document, LSR is used as a generic term. It is
interchangeable with Network Element)
NE : Network Element
LSP : Label Switched Path
PDM : Packet Division Multiplexing
TDM : Time Division Multiplexing
SDM : Space Division Multiplexing
PS : Protection Switching
EMS : Element Management System
NMS : Network Management System
OCh : Optical Channel
OMS : Optical Multiplex Section
OTN : Optical Transport Network
OTS : Optical Transmission Section
PDH : Plesiochronous Digital Hierarchy
SDH : Synchronous Digital Hierarchy
SONET: Synchronous Optical Network
STM-N: Synchronous Transport Module of level N
STS-N: Synchronous Transport Signal of level N
TDM : Time Division Multiplexing
WDM : Wavelength Division Multiplexing
3. Introduction
A network is composed of a data (or transport) plane, a control plane, and a
management plane. The scope of the control plane is connection setup and
processes necessary to support this, such as neighbor discovery/link management,
routing, signaling, etc. Other network functions, such as fault management and
performance monitoring involve different roles and timescales and are outside of
the scope of the control plane.
Despite the differences that exist in the technology and operation of different
networks, especially within their data planes, all switched networks share very
similar characteristics in their control planes for connection management. MPLS
has the ability to separate between the control and forwarding aspects of
Y. Xu, et. al. [Page 4]
draft-many-ccamp-gmpls-framework-00.txt Jan. 2002
routing. This ability allows the extensions of MPLS protocol to encompass
different forwarding planes including that of circuit transport networks. For
this reason, there is significant interest throughout the industry to define a
Generalized MPLS control plane.
In general, the GMPLS control plane proposes to extend current MPLS signaling
and other IP based control protocols into different types of networks. GMPLS
should define a set of powerful tools that can be used for different
technologies and network scenarios. It should facilitate network inter-working
and simplify network operation.
Besides the commonalities, we also need to pay attention to the differences
between different types of networks. MPLS/IP based control protocols are
designed and optimized for packet switching networks. There are some
fundamentally different assumptions between the packet switching network and
circuit switching transport network. For example, control and transport planes
are typically independent of each other in circuit switching network. While in
IP network, control and user traffics are mixed together. Furthermore, there are
different service and operation requirements for different types of networks.
The GMPLS control plane, as a generalized control plane, should also be
flexible, or provide enough tools to accommodate all these differences and
requirements. Technology dependent extensions/modification should be introduced
in the control plane, when necessary, in order to account for inherent
peculiarities of the underlying technologies and networking contexts.
In this document, section 4 introduces the background and rationale for GMPLS
control plane. Section 5 highlights the service and implementation requirements
for GMPLS control plane from service providers' point of view. Section 6
discusses the functional building blocks of a generic GMPLS control plane and
illustrates that in order to be generalized for different technologies and their
specific application environments, what each functional component could assume,
what it "should" (instead of "how") accomplish, what are the generic procedures
and possible implementation options. Section 7 goes beyond functional
partitioning and a single network. It illustrates the LSP hierarchy, network
layering, network partitioning and their implications to the GMPLS control plane
design and operations. This section then presents how to achieve control plane
integration and options of GMPLS control plane operation models.
4. Background
GMPLS was initiated to develop a unified control plane for multiple switching
technologies. The following sub-sections give the background of transport
technologies, transport network control plane evolution, and rationale for
selecting a GMPLS control plane.
Y. Xu, et. al. [Page 5]
draft-many-ccamp-gmpls-framework-00.txt Jan. 2002
4.1 Transport Technology Overview
Time Division Multiplexing (TDM) of several digital signals into a single higher
rate signal is used to maximize the bandwidth efficiency of digital circuit
transport networks. The first generations of TDM systems, based on PDH
techniques, used bit interleaving and pulse stuffing for clock synchronization
across the tributaries. The resulting hierarchy required full de-multiplexing
for identification of tributary signals at each level of the hierarchy.
Contemporary TDM schemes such as SONET/SDH (Synchronous Optical
Network/Synchronous Digital Hierarchy) and OTN (Optical Transport Network) use
byte interleaving of tributary signals and the transport overheads necessary for
network management functions to define a multiplex hierarchy of single-channel
systems in which the tributaries are more directly identifiable. Currently, the
TDM hierarchy extends up to about 40Gbit/s.
Both SONET/SDH and OTN are optimized for optical transport. Wavelength Division
Multiplexing (WDM) may be used in combination with SONET/SDH or OTN to create
optical transport systems of many wavelengths, each wavelength serving as the
carrier of a TDM tributary channel. A transport bandwidth of a few Tbit/s
capacity can thereby be achieved on current WDM systems. Due to the nature of
analog impairment accumulation in WDM systems and possible limitations due to
fiber nonlinearities, there is typically a tradeoff between the maximum
tributary bit rate, the maximum number of tributaries, and the total
transmission distance achievable on a WDM system.
SONET, mostly used in North America, is defined in ANSI T1.105. It is based on a
basic building block of 51.840 Mbit/s (STS-1) and the hierarchical levels are
integrally related to that value. However, only certain values above STS-1 are
recognized by the ANSI specification (STS-1, STS-3, STS-24, STS-48, and STS-
192). This helps alignment with SDH which has the same basic frame structure but
is defined relative to integer multiples of the unit 155.520 Mb/s (STM-1) which
is exactly 3xSTS-1. The SDH signal structure and hierarchy is specified in ITU-
T Recommendation G.707 according to the network architectural principles for SDH
given in G.803. Although some differences in overhead assignment usage and
networking functions exist between SONET and SDH, these systems can be made to
interwork at the transport level of their mutually compatible hierarchical
levels.
OTN is a transport capability optimized for use of WDM technologies, enabling
the network manipulation of wavelengths. The architectural foundation of OTN is
defined in ITU-T Rec. G.872 and the signal structure and hierarchy is defined in
Rec. G.709. The optical transport network layered structure is comprised of
optical channel (OCh), optical multiplex section (OMS) and optical transmission
section (OTS) layer networks. The optical channel layer network provides end-
to-end networking of optical channels for transparently conveying client
information of varying format (e.g. PDH, SONET/SDH, cell based ATM, etc.). The
optical multiplex layer network provides functionality for networking of a
multi-wavelength optical signal (the OMS can also be a single-wavelength). The
optical transmission section layer network provides functionality for
transmission of optical signals on various types of optical media.
Y. Xu, et. al. [Page 6]
draft-many-ccamp-gmpls-framework-00.txt Jan. 2002
Each of these network layers of the OTN has related overheads for ensuring
integrity of that layer and enabling relevant operations and management
functions. In particular, the optical channel layer provides OCh supervisory
functions for enabling network level operations and management functions, such
as connection provisioning, quality of service parameter exchange and network
survivability. Similarly, the OMS and OTS overheads include the capabilities for
survivability at the optical multiplex section and optical transmission section
layers, respectively.
4.2 Control Plane Evolution and Options of Transport Network
Currently, transport networks providing the capability to establish, tear down
and maintain end-to-end circuit connections have virtually no automatic network
control. Networks providing SONET/SDH and, possibly, wavelength services are
provisioned via vendor Element Management Systems (EMS) and operator Network
Management Systems (NMS). For a variety of reasons, the steps required for the
provisioning process are generally very slow relative to the switching speed,
often inaccurate, and frustrating to users who want quick turn-up of service and
the flexibility to change networks resources dedicated to their use. It is
often costly to network operators in terms of delayed or lost revenue and the
expenses required to integrate various vendors equipment into the network and
its NMS due to the hierarchical, centralized architecture and proprietary
implementations of the various management systems.
Connections can be established either by provisioning, signaling, or a hybrid
combination of these:
-- In the provisioning method, a connection is established by configuring every
network element along the path with the required information to establish an
end-to-end connection. Provisioning is provided either by means of
management systems or by manually creating "hard" permanent connections. A
network management system is used to access a database model of the network
to first establish the most suitable route and then to send commands to each
network element, involved in that route, to support the connection.
-- In the signaling method, a connection is established on demand by the
communicating end points within the control plane using a dynamic protocol
message exchange in the form of signaling messages. The resulting switched
connection requires network naming and addressing schemes as well as the
supporting control plane protocols to achieve inter-working solutions.
-- In the hybrid method, a network provides a permanent connection at the edge
of the network and utilizes a switched connection within the network to
provide end-to-end connections between the permanent connections at the
network edges. Appropriate signaling and routing protocols are then used to
establish the end-to-end network connections. Provisioning is therefore
required only on the edge connections. This type of network connection is
known as a "soft" permanent connection. From the user's perspective, a soft
Y. Xu, et. al. [Page 7]
draft-many-ccamp-gmpls-framework-00.txt Jan. 2002
permanent connection appears as a provisioned, management-controlled
permanent connection.
The major difference among these methods is the party that establishes the
connection. In the case of provisioning, the connection is set up by the
network operator. In the case of signaling, the connection set-up may also be
the responsibility of the end user but could also be done by third party
signaling.
The evolution of network capabilities is toward requirements for quick
connection setup, which can best be accomplished by the signaling or hybrid
connection establishment methods, supported by automated discovery of the
network resources. Automated discovery of network topology, required to support
identification of feasible connections, can be accomplished either by
centralized or distributed methods.
4.3 Motivation for GMPLS Control Plane
There are many candidates for the control plane for circuit switched networks,
e.g. PNNI, SS7, etc. A GMPLS control plane offers the following attributes:
-- It is ideally suited for networks where the primary services offered are
IP/MPLS -based, and/or the operators utilize (or are moving towards) data-
oriented operations and management paradigms. This simplifies network
administration across IP/MPLS - and non-IP/MPLS based networks via increased
uniformity of control and management semantics, and hence improved control
coordination across LSRs and circuit-switched network elements.
-- Recent advances in MPLS control plane technology can be leveraged, in
addition to accumulated operational experience with IP distributed routing
control.
-- Software artifacts, originally developed for the MPLS traffic engineering
application, can be utilized as a basis for transport control plane software,
with appropriate extensions/modifications. Consequently, this fosters the
rapid development and deployment of a new class of transport devices such as
PXCs and OXCs.
-- GMPLS control plane facilitates the introduction of control coordination
concepts between any kind of network devices, PXCs, OXCs and LSRs. GMPLS can
provide the efficient unified "control-plane service" needed by the IP/MPLS,
SDH/Sonet and OTN layers. Using the same paradigm and the same signaling and
routing protocol suite to control multiple layers will not only reduce the
overall complexity of designing, deploying and maintaining transmission
networks but also allow potentially two or more contiguous layers to inter-
operate no matter the partitioning of the network.
In general, a common signaling and protocol suite for distributed control of
Y. Xu, et. al. [Page 8]
draft-many-ccamp-gmpls-framework-00.txt Jan. 2002
circuit switched networks facilitates multi-layer circuit establishment across
heterogeneous transport networks, and reduces the overall complexity of
designing, deploying, and maintaining such networks. It additionally facilitates
the introduction of new networking and service capabilities, such as fast
distributed restoration that can introduce significant infrastructure cost
savings.
5 GMPLS Control Plane Functions and Goals
GMPLS control plane deals primarily with connection management, including
packet connection service and circuit connection service, which are
parts of the overall network management functions; the other parts
include aspects of accounting management, performance management,
security management, and policy management, etc. GMPLS control plane
is fundamentally a IP-based distributed connection control. This does
not preclude a common usage of GMPLS together with other solutions
such as centralized network management systems.
The text below highlights some high level functions and service requirements
from carriers. Detailed requirements are in [CARR-REQ].
-- Operation Automation
The control plane encompasses distributed management functions and
interfaces required for automatic connection management in a network.
One of the most fundamental goals of a control plane is to automate
operations. The GMPLS distributed control plane should provide
carriers with enhanced network control capabilities and relieve operators
from unnecessary, painful and time consuming manual operations. At the
same time, it should facilitate control plane interoperation and
integration between networks with different data plane technologies.
-- Path Selection Optimization
The selection of the LSP explicit route in a GMPLS controlled network
should be optimized to ensure effective and efficient network resource
utilization and other satisfactory performance.
-- Fast Restoration of Data Path
Restoration of data path may be performed by pre-selected (offline)
or on-line real-time path computations. Off-line computation may be
facilitated by simulation and/or network planning tools. Off-line computation
can help provide guidance to subsequent real-time computations. It is
expected that on-line computation and distributed restoration mechanisms will
provide shorter restoration time than the one available today with
centralized NMS.
Restoration may be complicated by the simultaneous control plane data
communication network failure. In order to guarantee to the data path
Y. Xu, et. al. [Page 9]
draft-many-ccamp-gmpls-framework-00.txt Jan. 2002
restoration requirements, control plane DCN should be engineered
reliable with build-in reliability mechanisms.
-- Alarm handling
Alarms relating to the control plane managed entity itself must be
reported to the management plane. The alarm handling depends on the
management plane. It is expected for SNMP based implementations that
alarm reporting mechanisms and conventions be consistent with what is being
specified in the IETF DISMAN working group.
More generically, the following requirements are expected from a GMPLS based
distributed control plane encompassing multi-layer transport networks:
-- Scalability
The performance of the control plane should not largely depend on the
scale of the network to which GMPLS is applied (e.g. the number of nodes,
the number of physical links, end etc.). The control plane should keep
constant performance as much as possible regardless of network size.
-- Flexibility
The control plane should have flexibility in its functionality and
provide operation full control and configurability.
6. Architectural Components of GMPLS Control Plane
This section studies the GMPLS control plane in the point view of functional
partitioning. Here, we look at a generic control plane of a single network.
Network partitioning, network layering and issues associated with control
plane interaction of multiple networks, control plane integration and control
plane operation models are discussed in section 7.
6.1 Overview
In general, a GMPLS control plane should:
-- Be applicable to all packet switching network and circuit switching
networks; e.g., IP, ATM, OTN, SONET/SDH, and PDH. In order to achieve this
goal, it is essential to isolate technology dependent aspects from
technology independent aspects and to address them separately.
-- Be sufficiently flexible to accommodate different network scenarios
(service provider business models). This goal must be achieved by
partitioning the control plane into a number of distinct functional
components. Each component may require more than one tools for different
network scenarios. Also, each tool needs to be configurable and
extensible. This, for example, allows vendors and service providers to
Y. Xu, et. al. [Page 10]
draft-many-ccamp-gmpls-framework-00.txt Jan. 2002
decide the logical placement of these components, and also allows the
service provider to decide the security and policy.
In the functional point of view, a GMPLS control plane can be partitioned into
the following functional components: neighbor discovery and link management,
routing, and signaling. The GMPLS control plane needs a data communication
network for control messages. It has interfaces to management plane and network
element hardware such as system controller, switching fabric.
Details of the control plane DCN and its functional components are elaborated in
following sub-sections.
6.2 Data Communication Network supporting GMPLS Control Plane
Before going to the functional components, we need to elaborate on the data
communication network for control plane first. The GMPLS control plane consists
of a set of distributed controllers that communicate and coordinate with each
other to achieve connection operations. A Data Communication Network (DCN) is
needed to enable control messages to be exchanged between controllers. For
conventional IP networks, there is no separated control plane network because
control and user data traffics share the same network. For circuit based
networks, an independent DCN is a fundamental requirement because a typical
circuit switch doesn't process user data traffic in its transport plane. In
order for GMPLS control plane to be applicable to circuit based networks, the
DCN concept MUST be introduced. The DCN supporting GMPLS control plane may use
different types of physical mediums:
-- The control traffic could be carried over a communication channel embedded
in the data-carrying circuit link between LSRs. For example, the medium
could be SONET/SDH or OTN overhead bytes
-- The control traffic could be carried over a separate communication channel
that shares the physical link with the data channels. For example, the
medium could be a dedicated wavelength, a STS-1 or a DS-1.
-- The control traffic could be carried over a dedicated communication link
between LSRs, separate from the data-bearing links. For example, the
medium could be a dedicated LAN or a point to point link.
6.2.1 GMPLS Control Plane Requirements for DCN
GMPLS control plane operations heavily depend on a DCN for exchanging control
messages. Thus, the DCN should satisfy following requirements:
-- The DCN supporting the GMPLS control plane MUST support IP.
-- The DCN should provide communications (either directly or in-directly)
between any pair of LSRs that need control traffic exchanging.
Y. Xu, et. al. [Page 11]
draft-many-ccamp-gmpls-framework-00.txt Jan. 2002
-- The DCN must be secure. This requirement stems from both signaling and
routing perspectives. The fact that the routing information exchanged over
the control plane is service-provider specific and security is critical.
Service providers may not want to expose internal network information outside
their network boundaries even to their own customers. Meanwhile, the control
plane network must prevent all kinds of attacking of connection services.
-- The DCN must be reliable and provide fault-tolerance. The DCN is the
transportation system for GMPLS control plane messages. If DCN fails, no
GMPLS message will be communicated among GMPLS controllers. DCN reliability
must be guaranteed, even during what might be considered catastrophic failure
scenarios of the service transport networks. Failures in the user-traffic
transport network that also affect the control plane DCN may result in the
inability to restore traffic or a degradation in the service restoration
time.
-- DCN should support message forwarding priority functionality. The overall
performance of GMPLS control plane largely depends on its control message
transportation. Time sensitive operations, such as protection switching, may
need certain QoS guarantees. Furthermore, message transportation should be
guaranteed or recovered quickly in event of control network failure.
-- The DCN should be extensible and scalable. The performance of DCN should not
explicitly depend on the network size, such as the number of nodes and number
of links. Since the GMPLS control plane supporting network be extended via
new network deployment.
-- Control plane DCN inter-working is the first step towards control plane
integration. It is desirable to have a common control plane DCN architecture
and protocol stack so that control planes of different networks could
communicate with each other.
6.2.2 De-coupling of the Control Plane and Transport Plane
GMPLS control plane should not make any assumptions about which type of physical
medium to use for its DCN, which implies that GMPLS control plane and its
transport plane should be de-coupled logically at least. This implication
affects the GMPLS control plane design in several aspects:
-- The control plane DCN may have a different physical topology from its
transport plane network such that a LSR's transport plane neighbor may not be
its control plane neighbor.
-- Transport plane neighbor discovery may need to depend on other mechanisms
other than DCN based neighbor discovery.
-- Control interfaces and transport interfaces may be de-coupled. Then it is not
required for two transport plane neighbors to have a direct control channel
Y. Xu, et. al. [Page 12]
draft-many-ccamp-gmpls-framework-00.txt Jan. 2002
as long as they are reachable through the DCN. This also implies that the
routing of control plane messages in the control plane DCN is logically
de-coupled from the routing of LSPs in the transport plane.
-- The health of control plane and transport plane should be maintained
independently. This requires separate notifications and status codes for the
control plane and transport plane. In the event of control plane failure (for
example, communications channel or control entity failure), new circuit LSP
(connection) operations may not be accepted, but existing connections shall
not be dropped. Connections in progress can be either left hanging, removed,
cranked back or continued once the failure in the control plane is resolved.
In any case it is imperative that the connections in progress not be left
partially setup (or hanging).
-- Signaling messages don't necessarily flow along the data path. So some of the
basic concepts in MPLS need to be re-defined for a broader scope.
-- Both IP based signaling and routing protocols should be enhanced to
accommodate this change.
6.2.3 Control Plane DCN Management Module
To support all the requirements mentioned in section 6.2.1, pure IP solution
needs to be enhanced. So there should be a build-in module to manage the GMPLS
control plane DCN. This module should include three functions (1) Control
Link/Channel Management (2) Control Route Management, and (2) Control Traffic
Management. The main objective of this component is to overcome link
degradations (failures or congestion) and keep the DCN reliability. To meet this
objective, the signaling management function is concerned with monitoring the
status of each control channel, with pre-selected alternate routes to overcome
link degradation.
This emphasis on the build-in management of the control plane DCN network is
rare; however, in GMPLS control plane, there are strong reasons for the emphasis
on internal DCN management:
-- The function being specified is critical. The performance of a network's
control plane DCN architecture affects all subscribers to the network.
-- The various networks involved must support multiple-vendors' control traffic.
Degradations in one carrier's control plane DCN will have repercussions
beyond that carrier's borders. Thus, some mutual agreement on the degree of
reliability of national DCNs is indicated.
-- Recovery and restoration actions may involve multiple networks. If GMPLS
control plane doesn't include failure and congestion recovery procedures, it
would be necessary for the administration of each public network to enter
into bilateral agreements with a number of other networks.
Y. Xu, et. al. [Page 13]
draft-many-ccamp-gmpls-framework-00.txt Jan. 2002
6.3 LSR Level Resource Discovery and Link Management
LSR resource discovery and link management is defined as the transaction that
establishes, verifies, updates and maintains the LSR adjacencies and their port-
pair association for their transport (data) plane.
6.3.1 The Output - LSR Level Resource Table
The resource discovery module is required to generate a complete LSR level
resource map, which include at least attributes, neighbor identifiers, and
pertinent real-time operational status. Examples of physical attributes are
signal type, payload type, optics types etc. Several physical attributes can be
abstracted into one logical attribute. Meanwhile, logical attributes may not be
assigned to a particular physical port directly, instead, they may describe
characteristics of a physical port pool. Examples of logical attributes examples
are: VPN ID, SRLG (Shared risk link group)[OPT-BUND] and Service type
It should be noticed that much of the information in the local resource map
might not be used by other control plane functions. They are used for fault
management, inventory management etc.
Furthermore, a LSR might have different types of neighbors. Its physical
adjacent neighbor may not be its switching neighbor. For example, two OXCs could
be inter-connected through DWDM transmission systems in the middle. These two
OXCs are switching neighbors even they are not physically adjacent. So a LSR may
maintain several local LSR level resource tables. The GMPLS control plane only
cares about resource tables of a LSR's switching neighbors. Other LSR level
resource tables may be used for fault management, inventory management etc.
6.3.2 Operation Procedures
Resource discovery and link management may include following operation steps:
-- Self resource awareness/discovery
The results of self resource awareness/discovery is to populate the
local ID, physical attributes, logical constraints parameters in the
element resource table.
-- Neighbor discovery and port association
This step discovers the adjacencies in the transport plane and
their port association and populates the neighbor LSR address and port
ID fields in the resource table.
Because the control plane network may be different from the
transport plane network in circuit switching network, LSRs that are not
adjacent in the control plane network may be adjacent in the transport
network. In order to unambiguously identify the transport plane neighbors and
Y. Xu, et. al. [Page 14]
draft-many-ccamp-gmpls-framework-00.txt Jan. 2002
their port associations, it is essential to have in-band events (along
the transport plane) coordinated with other control messages (along
the control plane).
An example of in-band events for LSRs capable of electrical signal
processing in the transport plane is a byte stream containing the
local LSR address and port ID. Bi-directional links may use in-band
signaling between both ends. Uni-directional links may employ messages
through the control network to coordinate with in-band signals to achieve
bi-directional control coordination.
For a pure OXC without O-E-O capability, an analog signal (power
on/off) could principally be used as the in-band event. Control
messages over the control network can then be used to co-ordinate
and associate additional significance with the in-band event to
identify neighbor adjacency and port associations. Details of this
type of scenario are for further study.
-- Resource verification and monitoring
After neighbor resource discovery, neighbors should detect their operation
states and verify their configurations such as physical attributes in order
to ensure compatibility. Such verification can be done through control
message over the control plane network without using in-band signals. In case
of any mismatch, the port should be marked as mis-configured, and
notification should be issued to operators.
Resource monitoring is a continual process. Neighbor discovery and
port association procedures are repeated periodically. Resource
monitoring procedures update resource state and report changes to
relevant control entities.
-- Service negotiation / discovery
Service negotiation essentially covers all aspects related to service
related to rules/policy negotiation between neighbors.
6.4 GMPLS Routing
The functionality of GMPLS control plane routing includes topology dissemination
and path selection of the LSPs in the transport/data plane..
-- Topology Information Dissemination
Topology information dissemination distribute topology information
throughout the network to form a consistent network level resource view
among LSRs. However, consistent view doesn't mean equal view. Since
networks may be partitioned into hierarchies according to business,
technological, geographical etc. considerations, LSRs are required to have
just need to equipped enough information to perform path selections at
different levels and granularities.
Y. Xu, et. al. [Page 15]
draft-many-ccamp-gmpls-framework-00.txt Jan. 2002
The key issue of topology dissemination is to answer "what", "to whom",
and "how" three questions. That is "what" information should be
distributed to "whom" and "how" to control the information dissemination.
-- Path Selection
The GMPLS path selection is a constrain-based computation procedure. This
procedure should conform to connection request constraints, such as
physical diversity, maximize network performance, adhere to management
policies, as well as conform to the network specific constraints.
Two most common used path selection mechanisms are hop by hope and
explicit path selection.
6.4.1 Topology Information Dissemination
The goal of topology information dissemination is to disseminate the sufficient
and necessary information effectively and efficiently to LSRs such that they are
able to select an optimized path. Major concerns for topology information
dissemination is scalability.
A typical transport core switch may contain thousands of physical ports. The
detailed link state information for a LSR could be huge. Scalability requires to
minimize global information propagation and keep detail information as well as
decision-making locally as much as possible.
To achieve scalability, the routing protocol should support different levels of
aggregations.
-- At the LSR level, parallel link connections should be summarized into an
aggregate bundle link, which hides the link connection details and only
the summarized information is distributed to the entire network. A bundle
is defined as a collection of link connections that share some common
logical or physical attributes that are significant for path selection
purposes. The specific links inside a bundle link should be equivalent for
routing purposes. The bundling granularity should be carefully considered
and engineered because too few information propagated will hurt
operational performance.
-- At the network level, the GMPLS routing protocol should support hierarchy
routing. Topology information of a sub-network is aggregated and
abstracted when disseminating to other sub-networks. At the AS boundary,
information is also filtered according to local policies. However, the
level of network hierarchy should be well evaluated. Too many hierarchies
may hurt network performance because the abstraction and aggregation may
not generate the "optimal" paths.
Scalability also requires controlling the information updating frequency. The
following optimization techniques should be considered in GMPLS control plane
routing protocol.
Y. Xu, et. al. [Page 16]
draft-many-ccamp-gmpls-framework-00.txt Jan. 2002
-- Differentiate static and dynamic information and update only the delta.
-- Control the update frequency through different types of thresholds.
Generally, two types of thresholds could be defined: absolute threshold
and relative threshold.
(1) Absolute threshold defines resource change difference.
(2) Relative threshold describes percent changes relative to previous data.
There is a tradeoff between accuracy of the topology and the GMPLS control plane
scalability. The GMPLS control plane should be designed such that network
operators are able to have the flexibility to adjust the balance according to
their networks' specific characteristics.
6.4.2 Path Selection
Path selection could be done either off-line at the network planning time or on-
line at real time. The choice depends upon the computational complexity,
topology information availability, and specific network context. Both off-line
and on-line path selection may be provided. For example, operators could use on-
line computation to handle a subset of path selection decisions and use off-line
computation for complicated traffic engineering and policy related issues such
as demand planning, service scheduling, cost modeling and global optimization.
This document does not discuss the specific path selection algorithms. But in
general, following input and output of path selection should be satisfied.
-- Path Selection Input
The inputs for path selection includes circuit connection end points, a
set of requested routing constraints and constraints of the network.
The requested constraints include bandwidth requirement, diversity
requirements, inclusion/exclusion hop list, etc. One of the major services
provided by a GMPLS control plane is fast restoration. Restoration is
often provided by either pre-computing or finding diversified routes for
connections in real-time. There are different levels of diversity
requirements. The simplest form of diversity is node diversification. More
complete notions of diversity can be addressed by logical attributes such
as shared risk link groups (SRLG), which can be abstracted by operators
from several physical attributes such as fiber trench ID and destructive
areas.
There are also constraints imposed by the networks. Some of these
constraints are generic, such as connectivity, bandwidth availability. Some
are technology dependent, such as those addressed by [OLCP].
-- Path Selection Output
For the intra-AS, the result of path selection is a list of explicit
routed path which satisfies the connection requirements. This path should
provide enough information for each LSR to choose the appropriate physical
resource for connection operation. For example the details of the hop
Y. Xu, et. al. [Page 17]
draft-many-ccamp-gmpls-framework-00.txt Jan. 2002
could be in link bundle level.
If the path across multiple carriers, the output of path selection may
include a list of AS-es or simply next AS.
6.4.3 Inter-AS vs. Intra-AS
Intra-AS routing and inter-AS routing have different requirements and may need
different tool sets.
In intra-AS routing, there is no trust boundary between network interfaces. Then
link state based IGPs (such as OSPF, ISIS) should be appropriate to the link
state information dissemination. In order to make the link state information
routing scalable, a LSR's Link state information should be the summary of its
local LSR level resource information and hiding the detail LSR level resource
locally.
The routing protocol may further decompose the link state information into
static information and dynamic information.
-- Static information does not change due to connection operations, such
as neighbor relationship, bundle link attributes, total bundle link
bandwidth, etc.
-- Dynamic information updates due to operations, such as bundle link
bandwidth availability, bundle link bandwidth fragmentation, etc.
The design of GMPLS control plane should consider the difference of these
two types of information. The tradeoff between routing scalability and
information availability is one of the key issues of GMPLS control plane
routing. The bottom line is that routing should provide enough link state
information such that constraint-based path selection for intra-AS routing
becomes available.
With detailed link state information available, the path selection for
intra-domain routing is normally constraint-based explicit routing.
In inter-AS routing, there exists strong trust boundary between carrier
networks. Then policy based EGPs should be appropriate for inter-AS routing. EGP
distributes reachability information without internal network information and
maintains a clear separation between distinct AS networks. Policy based control
gives operators configurable control of the topology dissemination.
The path selection in inter-AS case is typically hop-by-hop because different AS
may have different policies and concerns. A provider may not want to follow the
path selection result of another provider. In the inter-domain case, the hop
granularity is AS.
Y. Xu, et. al. [Page 18]
draft-many-ccamp-gmpls-framework-00.txt Jan. 2002
6.5 GMPLS signaling
Signaling is one of the key components of GMPLS control plane. The basic
functions include LSP creation, LSP deletion, LSP modification, LSP error
reporting, LSP error handling, as well as LSP restoration. In order to provide a
robust and efficient GMPLS control plane signaling protocol, the following are
some basic framework guidelines.
6.5.1 Basic Functions
GMPLS control plane was assumed to support both IP network and transport
network. GMPLS should inherit all signaling functions of MPLS, such as LSP
creating, LSP deletion, LSP modification, signaling error handling, etc. Except
these, GMPLS signaling protocol has some other functional requirements. Because
the transport network carries huge bandwidth and supports many applications, a
network failure, such as a fiber cut, will affect many applications. Fast
failure detection and fast LSP restoration become basic requirements for
transport networks that require support for high reliability and availability
for application connectivity. In summary, GMPLS control plane signaling should
support:
-- LSP creation
-- LSP deletion
-- LSP modification
-- LSP restoration
-- LSP exception handling
-- Creation Operation
An LSP creation operation starts when the ingress GMPLS node receives an LSP
request. This node usually performs certain processes of authorization
including admission control and resource verification. If the authorization
is confirmed, the ingress GMPLS node should select a path for the LSP with
available information and start the creation operation. A LSP creation
message will travel from the ingress node to the egress node along the
selected path. In transport networks, an Acknowledgement message is required
from the egress node to the ingress node. For bi-directional LSPs, three way
handshaking messages should provide in the signaling protocol to inform both
sides of the establishment of the LSP.
During LSP creation operation, the resources may either be allocated first,
or allocated after the entire path has been reserved. In a network where the
allocation procedure may take some finite time, fast LSP creation may suggest
that allocation be performed in the forward path. This may have consequences
if a downstream node denies this LSP request and cause the upstream nodes to
de-allocate the resources.
-- Deletion Operation
When an LSP is not needed anymore or an LSP has been given up by network, the
Y. Xu, et. al. [Page 19]
draft-many-ccamp-gmpls-framework-00.txt Jan. 2002
resources occupied by this LSP should be released. A deletion request message
should be provided in the signaling protocol. The deletion operation may
start from the ingress GMPLS node, the egress GMPLS node, or any middle GMPLS
node of the LSP. The deletion signaling should be designed to handle all
these cases.
In transport networks, partially deleted LSPs are serious problems. During
LSP deletion, a failed GMPLS node along the LSP may cause incomplete LSP
deletion. A deletion acknowledgement message is required by the initiating
node to guarantee the deletion completion. During the deletion operation,
race conditions may occur between the deletion request message and the de-
allocation of resources. Based on this race condition, certain alarms may be
raised at the downstream nodes. To support such an environment, a mechanism
is needed to allow for disabling/enabling of the alarms associated with the
LSP prior to de-allocation of resources.
Two alternatives may be envisioned to avoid this problem:
-- The downstream nodes will be informed through LSP frames, something
similar to SONET APS signal.
-- The downstream nodes will be notified through part of the deletion
message. After confirmation, they de-allocate the resource.
-- Modification operation
An LSP may be required to modify its attributes, such as bandwidth. A basic
requirement of LSP modification is so-called "make-before-break". The
signaling protocol should be designed to support this functionality. A
possible solution may involve resource sharing between the old LSP and the
new LSP.
6.5.2 Support of Restoration
Rapid restoration from network failures is a crucial aspect of current and
future transport networks. Rapid restoration is required by transport network
providers to support high reliability and availability for customer
connectivity. The choice of a restoration policy is a tradeoff between network
resource utilization (cost) and service interruption time. Clearly, minimized
service interruption time is desirable, but schemes achieving this usually do so
at the expense of network resource utilization, resulting in increased cost to
the provider. Different restoration schemes operate with different tradeoffs
between spare capacity requirements and service interruption time. In light of
these tradeoffs, transport providers are expected to support a range of
different service offerings, with a strong differentiating factor between these
service offerings being service interruption time in the event of network
failures. For example, a provider's highest offered service level would
generally ensure the most rapid recovery from network failures. However, such Y.
Xu, et. al. [Page 20]
draft-many-ccamp-gmpls-framework-00.txt Jan. 2002
schemes (e.g., 1+1, 1:1 protection) generally use a large amount of spare
restoration capacity, and are thus not cost effective for most customer
applications. Significant reductions in spare capacity can be achieved by
instead sharing this capacity across multiple independent failures.
GMPLS signaling should consider restoration and support multiple restoration
schemes, such as link protection, dedicated path protection, mesh shared path
restoration, dynamic rerouting restoration. Different applications may have
different requirements. GMPLS restoration schemes should include at least link
protection, dedicated path protection, mesh shared path restoration, and dynamic
rerouting.
6.5.3 Support of Exception handling
Different levels of exceptions may occur within the GMPLS network, impacting
both the data plane and the control plane. The following exceptions should be
considered in the GMPLS signaling design:
-- Ingress node, mediate nodes, egress nodes may deny the LSP creation. If the
resources are allocated before LSP confirmation, the deny of creation should
trigger the de-allocation of these resources.
-- A node detects the failure of an LSP. If restoration is provided, this
exception should trigger the restoration process of this LSP.
-- An LSP restoration process fails, for reasons such as GMPLS control plane
along the restoration path failure or lack of resources along the restoration
path. The exception should trigger the de-allocation of partially allocated
resources for this restoration LSP immediately such that those resources
are available other LSP creations and LSP restorations.
-- An LSP deletion process fails due to control plane failure along the LSP
path. This exception should be well handled such that no partially undeleted
LSPs exist in the network.
Unexpected exceptions may also happen. GMPLS signaling should be prepared to
handle some other unexpected exceptions, such as GMPLS control plane
implementation errors, hardware errors, etc.
6.5.4 Signaling coordination
All the above signaling messages do not exist independently. Their functions and
operations should be well coordinated. Otherwise, one signaling message may
trigger other signaling message misbehaviors.
GMPLS signaling should distinguish between service path and restoration path
establishment. MPLS signaling may establish two link/node disjoint LSPs at the
same time for each request. The data traffic can be either split into these two
Y. Xu, et. al. [Page 21]
draft-many-ccamp-gmpls-framework-00.txt Jan. 2002
LSPs or forwarded into one path. Another path is used only when the first path
fails. This is feasible, because the second LSP does not consume any bandwidth
if no data is forwarded in this path. In transport network, the situation is
different. In order to use the bandwidth efficiently, the restoration path may
need to be established after the service path fails. The restoration path could
be pre-planned or computed on the fly. Another difference between service path
establish and restoration path establish is the time delay. Specifically,
restoration path establishment has a higher time delay requirement than service
path establishment.
GMPLS should be able to support both unidirectional LSPs and bi-directional
LSPs. Traditional telecommunication circuits are typically bi-directional.
Current research shows that the data traffic in Internet is asymmetric.
Unidirectional LSPs for data traffic are more reasonable. Although the services
of mixed uni-directional LSPs and bi-directional LSPs are not clear now, GMPLS
signaling protocol should be prepared to support both applications in the same
framework. This may create label contention between uni-directional LSP and bi-
directional LSP as well as between two bi-directional LSPs from opposite
directions. A consistent solution should be provided to solve the label
contention problem.
LSP deletion operation and LSP fast restoration process should be well
coordinated. The GMPLS control plane is a distributed system. One node operation
should not cause other nodes' misunderstanding. For example, if one node is
using detection of loss of light in an all-optical network to trigger the fast
restoration process, the far end node deletion operation may cause this node to
trigger a failure restoration attempt. GMPLS signaling protocol should be well
designed to avoid this situation.
A GMPLS control plane may fail. After recovery, the signaling protocol should
design some mechanisms to synchronize the LSP management information bases
(MIBs) and link resources with its neighbors. During the control plane failure
period, LSPs may be deleted and link resources may be updated. Two possible
solutions could be:
-- Using neighbor query messages to synchronize its information base.
-- Using LSP refresh messages to synchronize its information base.
Y. Xu, et. al. [Page 22]
draft-many-ccamp-gmpls-framework-00.txt Jan. 2002
7. GMPLS Operation Models and Control Plane Integration
Section 6 describes the functional building blocks of a GMPLS control plane of a
single network. This section discusses network partitions, network layering and
issues associated with control plane interaction of multiple networks, control
plane integration, and control plane operation models.
Functional partitioning, network layering and network partitioning look at
a problem from different angles and provide a paramount picture of the GMPLS
control plane. They are designed for different purposes and complement each
other. It should be noted that a computational (section 7.1) model may or may
not be translated into specific protocol design and network partitioning
(section 7.2) directly. Protocols and network partitions are usually designed in
the engineering view as they take into account the decisions made to keep layers
separate or to combine them into single engineering components. Logical control
entities in the computational model may collapse or be integrated onto a single
entity. However, the computational model is a good tool to analyze the problem
and provide important inputs for protocol design and network partitioning.
7.1 LSP Hierarchy and the Network Layering
GMPLS [GMPLS-ARCH] defines five types of LSR interfaces: PSC interface, L2SC
interface, TDM interface, LSC interface and FSC interface. Accordingly, we
could view the network as having different conceptual layers: PSC layer, L2SC
layer, TDM layer, LSC layer and FSC layer. Within each of these layers multiple
sub-layers are possible. For example, the TDM layer may contain SONET/SDH,
which would be broken down into the LOVC and HOVC layers. Depending upon the
particular scenario, some layers (and sub-layers) might not be present. For
example, in a traditional IP over SONET scenario with no WDM functionality, the
LSC layer would not be present.
The layering shown figure 1 is intended to depict the inter-layer relationships
in the data (transport) plane. That is, the PSC layer can run over a TDM and
L2SC layer or it might also run directly over a LSC layer. A PSC layer would
not run directly over a FSC layer but instead either a TDM or LSC layer would be
in between. All layers eventually run over a FSC layer (here we are assuming an
optical fiber based network). TDM may run directly over FSC but most likely
would run over an LSC layer.
The layering in figure 1 also depicts a client/server relationship among the
layers. Here the upper layer plays the role of the client and the lower layer
plays the role of the server. For example, the PSC acts as a client to the TDM
and LSC. The LSC and TDM layers play the role of a server to the PSC layer. As
well, the LSC and TDM layers play the role of a client to the FSC layer.
Y. Xu, et. al. [Page 23]
draft-many-ccamp-gmpls-framework-00.txt Jan. 2002
+----------------------+
| PSC |
+----------------------+
| |
+-------+ |
| V |
| +------+ |
| | L2SC |--\ |
| +------+ \ |
| | \ |
+--------+ \ |
V \ |
+-------+ | |
| TDM | | |
+-------+ | |
| | V V
| | +---------+
| +--->| LSC |
| +---------+
V /
+--------+ /
| FSC |<--/
+--------+
Figure 1 Network Layering and Relationships
GMPLS doesn't have any restrictions on the mapping between control layers and
transport layers; e.g. a control plane instance may control several transport
layers. However, The network layering has critical impact on the control plane
design. LSPs at different layers are triggered by different events and may be
created at different times because of several mismatches such as switching
granularity and time-scale mismatches. For example, the bandwidth granularities
in different layers are different. IP link may be in the order of kbps; whereas
the size of a LSC link may be in units of 2.5G, 10G or higher. So it is
unpractical to set up an OC-48c pipe solely because of a 56kbps data LSP request.
These issues exist independent of network partitioning or control plane
operation models. For example, wile IP routers and OXCs are provisioned in a
single OSPF/ISIS area, mismatches still exist. In order to achieve control plane
integration, we need a new functional module to serve as a Bandwidth Broker
between networks of different layers.
We can look at this Bandwidth Broker function from another perspective. There
are two sets of functions associated with setting up a LSP.
1. "How" to automatically create/delete/modify a LSP and thus change the LSR
adjacency and client network topology?
Y. Xu, et. al. [Page 24]
draft-many-ccamp-gmpls-framework-00.txt Jan. 2002
The majority of current control plane work focuses on this area. The functional
components described in section 6 are for this "how" purpose.
2. "When" and "Where" to create/delete/modify a "what" LSP and thus change the
client network's LSR adjacency and network topology?
This set of functions makes up the Bandwidth Broker. This module resides in the
client network and decides "when" and "where" to create/delete/modify "what"
circuits through the server network. It can also be view as an automation of
part of a broader Network Planning function for the client layer. (Network
Planning makes decisions on installing fiber and network equipment for a network
based on forecast traffic demands.)
For IP network, the conventional IP layer control plane and Traffic Engineering
function assume that the IP network's physical topology is "static". However,
the GMPLS control plane enables the transport network control of an
automatically switched network. This new capability of the optical network has
changes the previous assumption of the IP layer. The Bandwidth Broker in the IP
layer is about how to use this new capacity of its transport network and request
the transport capacity where the IP traffic wants to be.
7.2 Network Partitioning and Control Plane Interfaces
For different network scenarios and partitions, GMPLS may need to provide a
different set of tools (a profile). The reason for studying network partitioning
is to understand what type of control plane interfaces need to be supported and
the tools and information flow of each interface.
Network partitioning refers to the administrative separation of a network into
separate sub-networks. It is in the operator's implementation point of view. The
network partitioning concept is a recursive definition where the limiting case
of partitioning of a network (or sub-network) is the network element itself (and
thus the fabric that provides a flexible connection function). We view the
overall network a collection of sub-networks. Each sub-network is a collection
of same/different types of NEs and/or sub-networks.
In order to understand network partitioning, we need to discuss the control
plane interfaces first. Communication is required by all entities that make up a
network's control plane. This includes communication between signaling functions
(this is one application where communication is carried over an interface) as
well as communication between routing functions, among others. In the context of
this framework document, control plane interfaces represent logical
relationships between control plane entities and are defined by the information
flow between these entities, as illustrated in the figure below. Such a
relationship allows distribution of these entities in support of different
equipment implementations and network architectures, as based on how the
functions are partitioned, how networks are partitioned, and what layer networks
are considered.
Y. Xu, et. al. [Page 25]
draft-many-ccamp-gmpls-framework-00.txt Jan. 2002
------ ------
/ \ / \
/ \ / \
| Control | | Control |
| Plane | Interface | Plane |
| Entity +---------------+ Entity |
| | | |
\ / \ /
\ / \ /
------ ------
Figure 2: Interface
The above information elements can be aggregated to form three types of control
plane interfaces, UNI, I-NNI and E-NNI as defined by ITU [G.807/Y1301]:
-- operations between user and network provider domains; user-network interface,
UNI
-- multi-vendor operation within a domain (administrative, vendor, technology,
political, etc.); interior node-node interface, I-NNI
-- multi-domain operation for a single network provider, or multi-domain
operation among different network providers; exterior node-node interface, E-
NNI
For these interfaces, although some similar types of information may flow over
the interface (e.g. connection service messages), the information content for
both routing and signaling may differ totally.
Operators may partition their network according to their administrative,
technological and/or geographical considerations. In order to understand the
principles of network partitioning; let's take a look at an example. In the case
of a single provider network, there are situations in which an E-NNI is
preferable to an I-NNI. Examples of such situations include the cases where the
provider network is comprised of multiple partitions arising from:
-- The use of different types of sub-networks(technology based), e.g. IP,
ATM, SONET, OTN etc.
-- The use of different vendors sub-networks
-- Interconnections of different sub-networks administered by different
business units
-- The consideration of control plane scalability and intention to reduce the
volume of topology information exchanged
As such, the type of interface between two applications are chosen as a result
of the type of information flow that is desired and what capabilities LSRs
support and not necessarily based on the administrative boundaries. In general,
network partitioning choice is decided by the interface type choice, which is
decided by the type of information flow between control plane entities. GMPLS
Y. Xu, et. al. [Page 26]
draft-many-ccamp-gmpls-framework-00.txt Jan. 2002
control plane should accommodate different network partitions. For each
interface, GMPLS should provide a profile (a set of tools) to meet the specific
requirements of the interface.
>From the network partitioning point of view, control plane could operate in different ways:
(1) Different transport layers could be partitioned into a single sub-network.
There could be one unified view for the entire span of the GMPLS layers
(PSC, TDM, LSC, FSC).
This implies that the GMPLS functional components would need to understand
all layers (e.g., extending routing protocol to have knowledge of all
layers). In essence you would have one type functional components that works
for all layers.
This variation may cause scalability problem. For example, a core
circuit switch typically has very limited packet processing power
comparing to a core IP router. If it is partitioned in the same AS as a
core IP router. Millions of IP routes that the core circuit switch
doesn't care can overload the core circuit switch easily.
(2) Different transport layers could be partitioned into different sub-networks
using a client/server model to request resources between the layers. They
may not know each other's detailed topology. However, networks at different
layers are aware of each other through their control planes. Topology
dissemination across sub-network boundary is controlled by policy based
routing protocol to guarantee the right LSR to get the right information
and only the right information.
(3) The network could also be partitioned in the middle of (a) and (b).
It might make sense in some cases to partition LSRs of specific layers or
sub-layers into a single sub-network. For example, the cell and packet
layers within the PSC layer might be unified. Or it might make sense to
unify the TDM and LSC layers in some implementations.
7.3 Control Plane Operation Models
GMPLS should allow for a wide variety of control plane operation models and
architectures that meet different network operation scenarios. In section 6,
7.1, and 7.2, we studied GMPLS control plane from different perspectives. Now we
discuss different operation models of the GMPLS control plane.
>From the functional partitioning point of view, control plane can be identified
as:
(1) A fully-automated control plane which has all the functional components
implemented in GMPLS control plane, while
(2) A semi-automated control plane which may have management plane implement
some of the control plane functions.
Y. Xu, et. al. [Page 27]
draft-many-ccamp-gmpls-framework-00.txt Jan. 2002
>From the network layering point of view, we can identify two control plane
integration models:
(1) Fully-integrated control plane.
In this model, the Bandwidth Broker mentioned in section 7.1 is integrated
into the client LSR to handle the interaction between the network
layers. Thus in the operator point of view, he/she only needs to focus on
the service level functions and is not aware of the existence of multiple
layers/technologies.
(2) Semi-integrated control plane.
In this model, each computational layer is partitioned into independent
networks and has one independent control plane entity. Management systems
and operator interventions are needed to coordinate the various control
planes.
Details of these operation models will be elaborated further in later versions.
8. Security Considerations
Security is critical where different business domains interact. When service
invocations happen between business domains, encryption and authentication
mechanisms are required at the service interfaces. Within a single business
domain, strict security needs further study. However, the control plane network
should be isolated from user traffic to avoid sensitive information being leaked
out. Many details need further study.
9. Acknowledgment
The authors would like to thank Patrice Lamy, Harvey Epstein, Wesam Alanqar,
Tammy Ferris, Mark Jones, Maarten Vissers and Papadimitriou Dimitrifor their
helpful suggestions and comments on this work.
Y. Xu, et. al. [Page 28]
draft-many-ccamp-gmpls-framework-00.txt Jan. 2002
10. Authors' Addresses
Yangguang Xu 21-2A41, Eve Varma 3C 509,
1600 Osgood Street 101 Crawfords Corner Rd
Lucent Technologies, Inc. Lucent Technologies, Inc.
North Andover, MA 01845 Holmdel, NJ 07733-3030
Email: xuyg@lucent.com Email: evarma@lucent.com
Rudy Hoebeke Hirokazu Ishimatsu
Alcatel Japan Telecom Co. Ltd.
Francis Wellesplein 1, 2018 Antwerp, 2-9-1 Hatchobori, Chuo-ku,
Belgium Tokyo, 104-0032 Japan
Email: rudy.hoebeke@alcatel.be E-mail: hirokazu@japan-telecom.co.jp
Osama S. Aboul-Magd Michael Mayer
Nortel Networks P.O. Box 3511, Nortel Networks P.O. Box 402
Station "C" Ottawa, Ogdensburg, NY 13669
Ontario, Canada K1Y - 4H7 Email: mgm@nortelnetworks.com
Email: osama@nortelnetworks.com
Daniel O. Awduche Yong Xue
Movaz Global Network Architecture
Email: awduche@movaz.net UUNET/WorldCom Ashburn, Virginia
Email: yxue@uu.net
Curtis Brownmiller John Eaves
WorldCom TyCom
Richardson, TX 75082 1C-240, 250 Industrial Way West
Email: curtis.brownmiller@wcom.com Eatontown, NJ 07724
Email: jeaves@tycomltd.com
Guangzhi Li Lily Cheng
AT&T Lucent
Email: gli@research.att.com Lilycheng@lucent.com
Ananth Nagarajan Lynn Neir
Sprint Sprint
9300 Metcalf Ave 9300 Metcalf Ave
Overland Park Ks 66212, USA. Overland Park Ks 66212, USA.
ananth.nagarajan@mail.sprint.com lynn.neir@mail.sprint.com
Jennifer Yates, Monica Lazer
AT&T Labs AT&T
180 PARK AVE, P.O. BOX 971 900 ROUTE 202/206N PO BX 752
FLORHAM PARK, NJ 07932-0000 BEDMINSTER, NJ 07921-0000
jyates@research.att.com mlazer@att.com
Zhi-wei Lin
Lucent
Y. Xu, et. al. [Page 29]
draft-many-ccamp-gmpls-framework-00.txt Jan. 2002
3C-512
101 Crawfords Corner Rd
Holmdel, NJ 07733-3030
zwlin@lucent.com
11. Reference
TBD
Y. Xu, et. al. [Page 30]