Internet DRAFT - draft-freeland-octrl-cons
draft-freeland-octrl-cons
IP-Optical Working Group Darren Freeland
Neil Harrison
Sergio Inglima
Keith James
Alan McGuire
Shehzad Mirza
Stewart Ritchie
Mel Robinson
Ali Salman
Peter Willis
Internet Draft BT
Document: draft-freeland-octrl-cons-01.txt November 2000
Considerations on the development of an Optical Control Plane
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
Work on extensions to IP control protocols for reuse in the control
plane of optical transport networks has now been underway for around
a year in the MPLS and IPO groups. Recent discussions have however
highlighted a lack of defined requirements that should be met by
candidate protocols being considered for the optical control plane.
Indeed, there have been several requests for carriers to submit
their requirements. This draft provides one view of some (but by no
means all) of these requirements. A protocol independent approach
is taken, and the authors recommend that the design of any
particular facet of an optical control plane should take into
account the considerations made in this document.
Freeland et al 1
Considerations on the Development of an Optical Control Plane
November 2000
CONTENTS
1. INTRODUCTION
2. CURRENT STANDARDS WORK
2.1 Nature of the OTN User Plane
3. TYPES OF CONNECTION
4. CARRIER OPERATING MODELS
5. OPTICAL CONTROL REQUIREMENTS
5.1 Addressing
5.2 Signalling
5.3 Routing
5.4 Other Issues
6. CONCLUSIONS
7. SECURITY CONSIDERATIONS
8. REFERENCES
9. Author's Contact Details
1. INTRODUCTION
This draft gives consideration to some of the requirements that must
be met by an optical control plane for various operating models. A
brief summary of current standards activities with respect to
optical control is also given, including a discussion on the nature
of the optical layer user plane. A protocol independent approach is
taken throughout the document, and the authors recommend that any
particular control plane facet being considered for an optical
transport network should take into account the requirements defined
in this document.
2. CURRENT STANDARDS WORK
A framework for IP over optical networks has been considered in the
IETF [1]. Work is also underway on the extension of existing
protocols developed for the MPLS traffic engineering control plane
for application to the design of an optical network control plane as
discussed [2]. Specifically, this work is known as MPL(ambda)S or
O-MPLS and is a subset of G-MPLS or Generalised MPLS - the extension
of MPLS signalling to encompass a number of possible layer 1 network
technologies [3].
This implies extensions to CR-LDP and RSVP for signalling, OSPF and
IS-IS for resource discovery and routing, and the use of IP
addressing. It has been assumed that IP control protocols will be
suitable for the control plane of layer 1 networks, given that IP
traffic volumes will dominate these networks. The authors of this
draft argue that this assumption has not yet been proved to be the
right choice, given the nature of the optical transport network
Freeland et al 2
Considerations on the Development of an Optical Control Plane
November 2000
(OTN) and the requirements of carriers. Indeed there are counter
marketing opinions and statistics which compel us to consider the
existence of other client networks for a number of years to come.
For example, some operators will use ATM to carry traffic from third
generation mobile networks, and there is little, if any, slowing
down of the demand for ATM and leased-line services.
2.1 Nature of the OTN user-plane
User plane connections are separable entities from the control plane
in the OTN. In particular, user plane and control plane traffic
need not be congruently routed. This is one distinguishing feature
that does not apply to traditional IP connectionless (CNLS)
networks. More importantly however, the user-plane is transparent,
connection-oriented (CO) and has no practical buffering. In
essence, the OTN user-plane is completely agnostic regarding the
type of traffic it carries (indeed this is also true of other layer
1 technologies such as SDH/SONET, which can support ATM, IP, PDH
etc, encapsulated within fixed length frames).
A key feature of a layer 1 user plane is its ability to accommodate
large administrative bandwidth entities and have the flexibility to
accommodate new client layer networks as they are introduced. These
client layer networks may or may not be customer application
interfacing.
Given the CO and client-agnostic nature of the OTN, one cannot
logically draw the conclusion that a set of control-plane protocols
which were originally developed to suit a CNLS environment are the
'right choice' for the control plane of an OTN. Indeed, the only
valid justification for this is the re-use of an existing set of
protocols, which can save development effort. Based on this
argument, one would then have to ask why other control plane
protocols developed for a CO environment should not be used?
We have not seen any evidence that such an analysis has been carried
out.
Aside from the IETF, work is underway on optical control issues in
the ITU-T with the development of G.ason [4], and the OIF Carriers
Group have recently produced a requirements capture for the optical
UNI or User-Network Interface [5]. Both of these bodies are
generally taking a protocol independent approach of requirements
capture, with the goal of producing an architectural framework that
any suitable control protocols should be able to meet. As such,
this work is a useful foundation for work in the IETF.
3. TYPES OF CONNECTION
Freeland et al 3
Considerations on the Development of an Optical Control Plane
November 2000
The OTN must ultimately be able to support the following types of
connections:
A permanent optical channel set up by the network management system
via network management protocols (requires access to a database
model of the network topology. This approach has traditionally been
centralised, but need not be for the OTN).
A soft permanent optical channel set up by the network management
system, using network generated signalling and routing protocols to
establish connections (this requires a defined NNI - note that these
connections cannot be set up by a user, and in particular, do not
require a UNI).
A switched optical channel, which can be set up by the customer on
demand using signalling and routing protocols (requires naming and
addressing schemes and a UNI/NNI).
The OTN may support one or more of the above types of connection at
any given time in its evolution. The types of connection required
will initially be permanent optical channels, with a migration over
time towards switched optical channels (although both may coexist).
The intent is therefore to reuse features that are common to more
than one type of connection - minimising the impact on existing
networks and their operational procedures and support systems.
4. CARRIER OPERATING MODELS
The development of a control plane will ultimately be set within the
context of an operator's business model. Four main operating models
can be envisaged for an optical transport network. These are:
(a) ISP owning all of its own infrastructure (i.e including fibre
and duct to the customer premises).
(b) ISP leasing some or all of its capacity from a third party.
(c) Carriers carrier providing layer 1 services.
(d) Service provider offering multiple layer 1, 2 and 3 services
over a common infrastructure.
For some of these models the concept of a unified, single control
plane may seem attractive (especially for option (a)). However, it
is unlikely that just one of these models will apply to any
operator, and the model that is appropriate will change depending on
the application.
It should also be noted that very few, if any, ISP's own all of
their own infrastructure - most have to lease. Further, unless they
lease they will have a very restricted market, since no operator has
total global coverage 'to the duct'. Furthermore, as one considers
the SME/mass-markets then peering across NNI's with other operators
will be the normal mode of working, and NOT the exception.
Freeland et al 4
Considerations on the Development of an Optical Control Plane
November 2000
One aspect of concern when inter-working is the type of information
that may be conveyed between operators. Generally this will be
restricted to requests for service. This also suggests a clear
distinction between types of NNI - for example an NNI between
operators, and an NNI within a particular operator's administrative
domain.
A carrier's carrier at layer 1 only provides support for layer 1
services and its topology/resource is invisible to users of the
network at higher layers. In such a network all-optical cross-
connects with optical drop and insert but no access to client layers
are not visible to the client.
Finally, the need for an optical network to support multiple types
of client layer networks introduces a number of considerations.
Different types of client layer networks may have completely
different control planes. If more than one client layer network is
transported, it possible that each client will use a different
addressing scheme. De-coupling the client layer control plane from
the OTN control plane ensures that different client addressing
schemes can be supported. Furthermore, this will ensure that future
client layers need not be hampered by legacy technology.
The development of a control plane for the optical network that is
separate and distinct from any client layer(s) allows for the
existence of all of these business models. The authors therefore
recommend that the optical layer control plane should be independent
of any particular client layer.
Note that none of the above discussion places any restrictions on
the particular protocols that may be used for the OTN control-plane
implementation. It merely suggests separate instances of client and
server layer control planes, and as such does not preclude the re-
use of existing protocols.
5. OPTICAL CONTROL REQUIREMENTS
A control plane consists of four main facets:
- an addressing scheme;
- a signalling network that provides communication between entities
requesting service and entities that provision those services;
- a signalling protocol for the set-up, maintenance and tear-down of
trails;
- a routing process to handle topology/resource usage and route
calculation (this does not necessarily imply that an automated
routing protocol is the right approach in all cases however).
5.1 Addressing
Freeland et al 5
Considerations on the Development of an Optical Control Plane
November 2000
The number of trails per second that are set up in the OTN (indeed
traffic volumes in general) is likely to be at least equivalent to
what carriers currently have with SONET/SDH. The optical control
plane can therefore initially be expected to receive requests to set
up hundreds of trails per day per domain, with the potential to
scale to many more in the future. The OTN control pane should
therefore be designed to support in the region of tens of thousands
of connection requests per day. It follows that the OTN must have a
scalable naming and addressing scheme, capable of meeting expected
demand for new names and addresses over decades to come.
The benefits of the above cannot be achieved unless lead
times/provisioning for delivery of capacity are dramatically reduced
however. It is therefore essential that such a network provides
tools for capacity management, utilisation, statistics on failed
call attempts, plan and build facilities, providing ordering
triggers, and dealing with long term localised congestion.
A large proportion of carriers will require their OTN's to be multi-
client environments. This is evidenced through a number of carrier
contributions to various standards forums. The reasoning is that,
despite the fact traffic forecasts for the next few years do indeed
show IP traffic continuing to dominate networks worldwide, non-IP
traffic will not be inconsequential and therefore cannot be ignored.
One of the most important issues therefore relates to the addressing
scheme used in the server OTN and the various client networks.
Multiple client (e.g. ATM, PSTN, IP) layer addressing schemes must
be supported, therefore server OTN layer addressing should be
disjoint from any client layer addressing to ensure a true multi-
client server network.
This does not imply that the same type of addressing cannot be used
in both client and optical layer control planes - it simply means
that both schemes must be disjoint from one another. This would
also be in conformance to RFC 1958 [6], which mandates exactly the
same principle by requiring that "the internet level protocol must
be independent of the hardware medium and hardware addressing" and
that "this approach allows the internet to .. decouple it's
addressing mechanisms from the hardware".
5.2 Signalling
The design of a signalling network and its associated interfaces are
important issues for the optical control plane. The choice of
channel and transmission media for the network must be appropriate
to optical networks, and indeed any other layer 1 networks. If
signalling is always carried along the same physical link as the
actual traffic, a failure in that physical link will usually take
out the control plane as well as the user plane between the
Freeland et al 6
Considerations on the Development of an Optical Control Plane
November 2000
particular nodes. However, the signalling network does not have to
have the same physical topology as the traffic network - and indeed
a separate diverse topology has both functional advantages and can
be made more reliable (as a function of its own topological design
and its failure behaviour). In general, the control plane network
must always be more reliable than the user plane traffic network.
Signalling can either be carried in a channel associated or common
channel fashion. Channel associated signalling is a very simple
method used for early digital transmission systems, where a limited
number of signalling bits were added to the frame structure (which
also contained the associated traffic channel - i.e. the user-plane
and the control-plane share a common routing). This simplicity
meant the technique could not be extended to signalling for advanced
service features such as CLI, call waiting, etc (which are found in
the PSTN/ISDN).
On the other hand, it is desirable for common channel signalling to
use message-based structures within a channel that is usually not
congruently routed with the associated user-plane traffic. Although
slightly more complex to design, common channel signalling has
proven to be easier to update and modify as new service requirements
emerge. Common channel signalling is therefore the universal choice
for new systems. Common channel, channel associated, or a
combination of both should be used where appropriate in the OTN.
Interfaces within a control plane fall into two categories - client
to server (known as the User-Network Interface (UNI)) and server to
server (known as the Network-Network Interface (NNI)). There will
be different flavours of UNI and NNI, however for the purpose of
this section we will focus on the general requirements of the UNI
and NNI.
Common channel signalling is usually carried out-band, while channel
associated signalling is not. For an optical transmission system,
in-band signalling would result in a network where every signalling
node would have to examine all of the data passing through it in
order to find any signalling destined for it. This would be fine if
every optical network element was opaque to the user plane (and this
should be the case at a UNI), however there will be an increasing
(over time) number of occasions where all-optical network elements
(i.e. transparent to the user plane) are used within the OTN.
Transparent optical nodes that cannot access in-band signalling
information will therefore require an out-band data communications
network (sometimes known as a dedicated optical supervisory
channel).
This certainly applies to nodes within the OTN (i.e. NNI's), however
it will be possible to ensure that network elements at the ingress
and egress points of the network are opaque to the user plane (i.e.
perform optical-electronic-optical conversions, and can therefore
Freeland et al 7
Considerations on the Development of an Optical Control Plane
November 2000
easily access in-band signalling). Signalling for a UNI may
therefore be out-band or in-band.
Both UNIs and NNIs should be capable of supporting dynamic `dial up'
wavelength requests. For the UNI these requests will be client
initiated (for example from an IP router, ATM switch, or a client
layer network within the same network element), and for the NNI
these requests will be OTN initiated (for example from another
carriers' optical network element). The requesting party must first
specify the optical trail parameters required (e.g. protection
level, bandwidth, availability). It should be noted these service
level parameters require further study. The optical control
interface should support CAC (Connection Admission Control). CAC
should include authentication and permissibility of the user, and
verification of service level parameters. It should also support
billing systems as necessary, and provide a secure interface between
the OTN and it's various clients.
Every ingress node to the optical transport network should therefore
support CAC functionality, and inform the requesting party of
whether or not the circuit request has been successful. In the
event of an unsuccessful attempt, the requesting party should be
informed of the particular reasons why the request was rejected
(i.e. network busy, fault, etc). Signalling shall be achieved using
a message-based protocol rather than a bit-based protocol with
framing (as in SONET/SDH), since this allows for simple extensions.
The interfaces should support a number of typical signalling
messages such as requests for the set-up of connections, requests
for the removal of connections, accept or reject particular
requests, query connection attributes, etc (though as noted above
these service request parameters require further study). It is
important to note that any new service requests should not affect
existing user plane traffic connections.
All of the signalling requirements discussed in this section should
be supported by a candidate signalling protocol and should be
capable of being implemented in both a point-to-point fashion for
simple client-server communications, and a point to multi-point
fashion in order to support multicast client-server applications.
5.3 Routing
The OTN will consist of a number of administrative domains, owned by
different carriers. Here we must make a distinction over NNI's
between different optical entities in different administrative
domains, and NNI's between optical entities within an administrative
domain.
It should be noted that an automatic routing protocol may not always
be needed. For the purposes of this paper, we will however assume
that an automatic routing protocol is to be used.
Freeland et al 8
Considerations on the Development of an Optical Control Plane
November 2000
As well as the basic ability of route computation (e.g. finding the
'shortest' or 'constrained shortest' path to a particular
destination), dynamic routing protocols can have the additional
functionality of resource discovery. This has the advantages of
allowing the control plane to react dynamically to changes in
network state/loading, maintain up to date routing tables, and (in
certain scenarios) give a particular node full visibility of network
topology and available resource within it's domain.
In contrast to higher layer networks, the OTN will consist of
elements that will grow to the order of a thousand or more ports
(either in the wavelength domain or as physical interfaces). This
implies a larger number of links between neighbouring network
elements, and a greater number of adjacencies. Routing and topology
discovery protocols must therefore be able to scale in order to
support such network elements.
In the context of the OTN, resource discovery would only be
supported at NNI's within a carrier's administrative domain.
Carriers will not allow another carrier or private domain visibility
of either topology or resource (and certainly not resource control).
Therefore topology/resource discovery is unlikely to be supported
between different administrative domains. There may of course be
instances where there is high degree of trust between carriers, but
this would be a rare exception rather than the rule. In this
situation, the two parties may choose to use a standard NNI, or a
specific 'friendly' and proprietary NNI (which is outside the scope
of standardisation activities).
As well as not being supported at an NNI between different
administrative domains, topology/resource discovery is unlikely to
find favour between an optical network element and a particular
client of the OTN (unless the carrier owns ALL of its clients as
well). Along with the justification given in section 4.1 for
disjoint addressing across client and server layers, this reinforces
the requirement that the control plane for the optical layer should
be independent of any particular client.
5.4 Other issues
The basic and first to be standardised service for the optical
control plane should be a simple bi-directional point to point
connection - with a fixed grade of service and fixed bandwidth.
This service is the simplest to provision and initial development
should therefore focus on it. In the absence of
protection/restoration mechanisms, once a connection is dropped it
will only be re-established by means of a further connection
attempt. This may or may not be automated.
Freeland et al 9
Considerations on the Development of an Optical Control Plane
November 2000
Resilience issues must also be considered. The optical control
plane will be required to handle error detection/correction, and
flow control mechanisms for restricting the transmission of
signalling packets where appropriate (in other words, the OTN
control plane will need its own OAM). Focus here should initially
be restricted to the control plane, however there will be
requirements to develop these mechanisms for the user plane. As
discussed previously, the network for the control plane need not be
co-incident with that of the user plane. Indeed this would improve
resilience in the signalling network. The optical control plane
should in general be as robust and reliable as possible. In the
event of a signalling failure, the connection in the user plane must
not be affected.
The ability to change the topology of the client layer network both
quickly and flexibly (i.e. client layer links = server layer trails)
will bring a new dimension to traffic engineering (TE). Perhaps
even obviating much of the need for TE within a client layer
network. Topology distribution information must include sufficient
parameters to enable traffic to be balanced across available links
in the OTN (for example, percentage loading on the link).
Finally, the optical control plane must be secure enough to ensure
that the integrity of the OTN is not compromised, and that 'illegal'
service requests are dealt with in the appropriate manner. This
should be implemented by an appropriate CAC function.
6. CONCLUSIONS
In this paper we have covered some general requirements for the
control plane of an OTN. The following is a summarised list of
protocol independent requirements that any candidate control plane
for the OTN should be capable of supporting. This list is by no
means exhaustive, and as well as reserving the right to add to or
modify these recommendations, the authors encourage both open
discussion of them and suggested additions to the list.
- The OTN must allow a multi-client environment.
- The OTN layer control plane should be independent of any particular
client layer control plane.
- A naming and addressing scheme for the OTN control plane must be
scalable for decades to come.
- Addressing must be disjoint across client and optical layers.
- The OTN control network must be as robust and reliable as possible.
- Message based signalling should be used for OTN control.
- 'Modify' signalling messages must be non-traffic affecting.
- Signalling failures must be non-traffic affecting.
- NNI's must use out-band signalling.
- UNI's may use in-band or out-band signalling.
- Desirable connection parameters should be specified by the client
Freeland et al 10
Considerations on the Development of an Optical Control Plane
November 2000
at the UNI (e.g. protection level, availability, etc). These
require further study.
- Ingress optical nodes must support CAC functionality.
- CAC functionality should include user authentication &
permissibility, billing, security, and verification of service
level parameters.
- Ingress optical nodes must inform the client of whether the
connection request has been successful.
- Ingress optical node should inform the client of the reason(s)
behind an unsuccessful connection attempt.
- Point to point and point to multi-point client dial-up should be
supported across a UNI.
- The optical control plane should handle error detection/correction
and flow control (i.e have its own OAM).
- OAM focus should initially be restricted to the OTN control plane
(however there will be requirements to develop OAM for the OTN user
plane).
- Routing & topology discovery protocols must be able to scale to
support optical network elements with the order of a thousand or
more ports.
- Resource/topology discovery should not be supported between
administrative domains.
- Resource/topology discovery should not be supported at an UNI (i.e.
the client should not have direct visibility/control over the OTN
resources).
- Resource/topology discovery may be supported at an internal NNI
(i.e. within an administrative domain).
- Topology distribution parameters should support TE for the optical
layer.
- Simple bi-directional point to point connection should be the first
service to be standardised (fixed bandwidth & fixed grade of
service).
- Control plane requirements should be supported regardless of
whether optical network elements are transparent or opaque to the
user plane.
7. SECURITY CONSIDERATIONS
A key security consideration has been discussed in this draft
regarding routing protocols with topology/resource discovery
capabilities running at the boundaries of operator's administrative
domains. This would be unacceptable to the vast majority of
operators. To alleviate security issues, it has therefore been
recommended that resource discovery must not be supported at the
boundaries of administrative domains, and additionally that separate
control planes are implemented for both the client layer and OTN
server layer. Future revisions of the document may consider other
security issues.
Freeland et al 11
Considerations on the Development of an Optical Control Plane
November 2000
8. REFERENCES
[1] IP over Optical Networks: A Framework, Bala Rajagopolan et al,
Internet Draft, draft-many-ip-optical-framework-01.txt, Work in
Progress, July 2000.
[2] Multi-Protocol Lambda Switching: Combining MPLS Traffic
Engineering Control With Optical Crossconnects, Dan Awduche
et al, Internet Draft, draft-awduche-mpls-te-optical-02.txt, Work in
Progress, July 2000.
[3] Generalized MPLS: Signaling Functional Description, Peter
Ashwood-Smith et al, Internet Draft, draft-ietf-mpls-generalized-
signaling-01.txt, Work in Progress, November 2000.
[4] Architecture for the Automatic Switched Optical Network (ASON),
First draft of G.ason, ITU-T Study Group 13, Work in Progress, March
2000.
[5] Carrier Optical Services Framework and Associated Requirements
for UNI, OIF Carrier Group, T1X1.5 liason document, Work in
Progress, October 2000.
[6] Architectural Principles of the Internet, RFC 1958, B.Carpenter,
IAB, June 1996.
9. Author's Contact Details
Darren Freeland
BTexaCT
Email: darren.freeland@bt.com
Neil Harrison
BT/Ignite
Email: neil.2.harrison@bt.com
Sergio Inglima
BTexaCT
Email: sergio.inglima@bt.com
Keith James
BTexaCT
Email: keith.a.james@bt.com
Alan McGuire
BTexaCT
Email: alan.mcguire@bt.com
Shehzad Mirza
Freeland et al 12
Considerations on the Development of an Optical Control Plane
November 2000
BTexaCT
Email: shehzad.mirza@bt.com
Stewart Ritchie
BTexaCT
Email: stewart.ritchie@bt.com
Mel Robinson
BT/Ignite
Email: mel.robinson@bt.com
Ali Salman
BTexaCT
Email: ali.salman@bt.com
Peter Willis
BT CTO
Email: peter.j.willis@bt.com
Freeland et al 13
