Network Working Group D. Papadimitriou
Document: draft-papadimitriou-enhanced-lsps-04.txt J. Jones
Category: Internet Draft Alcatel
Expiration Date: January 2002
July 2001
Enhanced LSP Services in Optical Networks
draft-papadimitriou-enhanced-lsps-04.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.
Conventions used in this document:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [1].
Abstract
In the scope of the domain service model as defined in [IPO-FRM],
the main objective of this document is to integrate within the set
of services covered by this model Virtual Private optical Networks
(VPoN), Connection Survivability by using the Shared Risk Link Group
(SRLG) inference model, Class-of-Priorities and Class-of-Service
(CoS) as well as Waveband and Optical Multicast connection services.
Papadimitriou et al. Expires January 2002 1
draft-papadimitriou-enhanced-lsps-04.txt July 2001
1. Introduction
Current IP protocols extensions for Integrated or Differentiated
services, for Traffic-Engineering (Multi-Protocol Label Switching),
for privacy (Virtual Private Networks), for multicast applications
(IP Multicast protocols) and for security (IPSec Protocol) result
from the short-term perspective when the IP protocol was defined at
the beginning of the eighties. Now, the current developments on
optical networking are challenging the same problem: if these
features are not included from the beginning within the signalling
and routing protocols used in optical networking, future needs wonÆt
be covered by the current developments.
The main objective of this memo is to include within the LSP
connection services provided currently when using GMPLS-based
signalling and routing protocols, the following connections
services: the Virtual Private optical Network (VPoN), the Class-of-
Service (CoS), Waveband and Optical Multicast connection services.
Such services are really the ones (additional services can be
defined in the future) that will provide added value comparing to
the current situation in traditional optical networks.
In order to structure the integration of these services within the
signalling and routing protocols, we propose to separate the types
of information enabling the optical network to provide these
services. For an optical network controlled through a distributed
IP-based control plane optical sub-network we suggest here to
differentiate the identification and connection service information
available on each Optical LSR (OLSR) from the centralized
information (for instance, related to the network policy) available
through directory services. This means that we consider for
scalability, convergence and performance reasons that keeping all
the policy-related parameters would result in an overflow of
information to be distributed throughout the optical network giving
rise to an increasing convergence time of the optical network
routing database.
2. Optical Networks Foundation
This section briefly describes two examples of widely used optical
technologies that can provide enhanced LSP Services through the use
of an IP-based distributed control plane (such as the one defined by
the Generalized MPLS protocol suite) with a Domain Service Model.
The latter in described in section 2.2.
2.1 Transport Technologies for Optical Networking
The Optical Transport Network (OTN) defined in G.872 [ITUT-G872] and
G.709 [ITUT-G709] enables optical transmission of various client
signal types through the use of Forward Error Correction (FEC)
bytes. ITU-T G.872 defines a functional architecture for an optical
Papadimitriou et al. Expires January 2002 2
draft-papadimitriou-enhanced-lsps-04.txt July 2001
transport network that supports the transport of digital client
signals. ITU-T G.709 recommendation specifies the data plane
transport structure and allocates overhead bytes for the OTN control
plane. It defines the digital path structure to be transported into
optical channels.
In the below sub-sections section, we describe shortly the G.709
Digital and Optical Transport Hierarchies (OTH) defined at the ITU-
T. This by taking into account that today the most widely deployed
legacy transmission networks (in particular in Wide Area Networks -
WAN) are based on SDH and SONET. More details on OTN and Pre-OTN
developments can be found in [G709-FRM].
2.1.1 Pre-OTN DWDM Development
ITU-T G.709 describes pre-OTN development (also referred to as DWDM
development) for backward compatibility with the current DWDM system
deployment. Pre-OTN DWDM systems (which were not defined at the ITU
prior to the G.709 recommendation) have been developed during the
last years in order to overcome the bandwidth limitations and
increase the bit-rate per fiber until several Tbps per fiber. In the
future, pre-OTN DWDM systems will provide up to hundred of
wavelengths per fiber.
These developments include the definition of point-to-point DWDM
optical channels on top of a mesh optical topology including Optical
Cross-Connects (OXC) or Photonic Cross-Connects (PXC). A PXC is
defined as an all-optical device (i.e. no O/E/O interface
conversion) so that 1R optical amplification can be provided by such
interfaces. Conversely, an OXC is defined as a non-transparent
device providing O/E/O conversion at each interface (also referred
to as 3R for Reamplification, Reshaping and Retiming) such devices
are capable to switch a whole STM-N/OC-N signal or MSn/STS-N signal.
Thus the Regenerator Section or the Multiplex Section is
respectively terminated (at least for certain overhead bytes) by the
switch interfaces. This means that such devices donÆt provide the
so-called VC-4/STS-1 SPE re-grooming capability. On the contrary, an
Opaque OXC is defined in the scope of this document as a VC-4/STS-1
SPE SDH/Sonet cross-connect, which is therefore strictly equivalent
to a DXC with optical transceivers on its line interfaces.
The current bandwidth bottleneck is overcome by the use of DWDM
systems. Today, DWDM systems allow the multiplexing of more than 160
wavelengths of 10 Gbps (1.6 Tbps per fiber with a 25 GHz spacing)
using the C-band and the L-band. Recent optical technology
improvements enable channel spacing of 12.5 GHz for 2.5 Gbps
signals. Consequently, it will be possible to house 320 wavelengths
of 2.5 Gbps in a single fiber. A complementary method for increasing
the effective capacity of a DWDM system is to include the 1480nm
(Short Band) and 1650nm (Ultra-Long Band) bands by providing fibers
covering ultra-wide optical bands from 1460 to 1675nm.
Papadimitriou et al. Expires January 2002 3
draft-papadimitriou-enhanced-lsps-04.txt July 2001
In the pre-OTN application, client signals are either directly
mapped on the wavelength (i.e. optical channel) or mapped through by
using an intermediate mapping-framing variable-length layer also
referred to as a digital wrapper layer. The former direct mapping is
defined for STM-N/OC-N (and Gigabit Ethernet) client signal while
the latter is mainly used for packet client layers such as IP and
ATM. This means that such developments do not include G.709 client-
signal mapping specification through the definition of a dedicated
framing procedure. Moreover, additional standard Transparency levels
to the one defined for SONET/SDH networks can be specified for Pre-
OTN networks.
2.1.2 Optical Transport Networks (OTN)
Optical networks comprise a set of functionality providing
transport, multiplexing, routing, supervision and survivability of
client signals that are processed predominantly in the optical
domain. Optical signals are characterized by wavelength and may be
processed per wavelength or as a wavelength division multiplexed
group of wavelengths.
The OTN model is decomposed into independent (transport) network
layers where each layer can be separately partitioned in a way that
reflects its internal structure. Thus, the OTN model refers to a
layered structure comprising a Digital and an Optical Transport
Hierarchy (OTH).
The development of a digital and an optical transport hierarchy
(i.e. networking layer) is required for the following reasons:
- It is the next step (after TDM - SDH/SONET) to support ever
growing data driven needs for bandwidth and emergence of new
broadband services
- To support next generation Terabit/second per fiber via DWDM lines
at the transport level as well as optical channels at 2.5 Gbps, 10
Gbps and 40 Gbps bit rates at wire speed level (and in the future
160 Gbps currently under definition)
- To provide network operational management, planning,
administration, survivability, and finally cost of maintenance
limited only to the OTUk/ODUk rates of transmission without caring
about the granularity of the client signal.
In the optical domain, the following network layers are currently
defined, they constitute the Optical Transport Hierarchy:
- Optical Transmission Section (OTS) layer: This network layer
provides functionality for transmission of optical signals on
optical media of various types. This layer ensures the integrity
and maintenance of the optical transmitted signal by overhead
processing.
- Optical Multiplex Section (OMS) layer: This network layer provides
functionality for networking of a multi-wavelength optical signal.
A "multi-wavelength" signal includes the case of just one optical
channel. This layer ensures the integrity and maintenance of the
Papadimitriou et al. Expires January 2002 4
draft-papadimitriou-enhanced-lsps-04.txt July 2001
multi-wavelength signal by overhead processing.
- Optical Channel (OCh) layer: this network layer provides end-to-
end networking of optical channels for transparently conveying
client information of various formats (e.g. SDH STM-N, Sonet OC-N,
ATM, IP, etc.). The capabilities of this network layer concern
connection re-arrangement for flexible routing, overhead
processing, administration and maintenance functions.
For the three layers specified above, non-associated overhead is
transported via the Optical Supervisory Channel (OSC) in order to
manage the optical connectivity. It has to be noted that these three
layers are common to both pre-OTN and OTN applications.
STM-N GbE ATM GFP
| | | |
| | | |
v v v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ========================
| OCh Payload Unit (OPUk) |
STM-N GbE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------------------------
| | | OCh Data Unit (ODUk) | Digital Path Layer
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------------------------
v v | OCh Transport Unit (OTUk) | Digital Section Layer
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ========================
| Optical Channel Layer (OCh) |
+-----------------------------------------+ Optical Channel Layer
| Optical Channel Multiplexing |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ========================
| Optical Multiplex Section OMS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Optical Physical Section
| Optical Transmission Section OTS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ========================
As far as the client signal handling is concerned, the Digital
Wrapper layer is further layered as follows:
- The Optical Channel Transport Unit (OTUk) provides FEC
capabilities and optical section protection and monitoring
capabilities.
- The Optical Channel Data Unit (ODUk) layer provides client
independent connectivity, connection protection and monitoring
(also without the need to terminate the overhead information,
the ODUk overhead may be monitored non-intrusively).
- Clients signals i.e. STM-N signals, IP packets, ATM cells and
Ethernet frames are mapped (meaning digitally wrapped) into a new
structured frame defined as Optical Channel Payload Unit (OPUk).
For each of the three layers specified above, an associated (in-
band) overhead carrying the management information is added inside
the framed structure itself. Notice, that only the ODUk (k= 1, 2, 3)
and OCh are defined today as networking layers. The OPUk, ODUk and
OTUk layers constitute the Digital Transport Hierarchy also referred
to as the Digital Wrapper Layer.
Papadimitriou et al. Expires January 2002 5
draft-papadimitriou-enhanced-lsps-04.txt July 2001
2.2 Service Models for Optical Networking
Two service models are generally considered for the services at the
boundary between distinct administrative entities (sometimes
corresponding to separate technological domain or clouds): the
domain service and the unified service model. The former is largely
covered in [GMPLS-ARCH] and [IPO-FRM] while the latter is discussed
more extensively in this section in particular from the connection
service perspective.
Under the domain service model, the transport network primarily
offers high bandwidth connectivity in the form of Lambda Switched
LSP (L-LSP). The client LSR when requesting the following connection
services uses standardized signalling protocols across the domain
service interface: LSP creation/deletion/modification (non-
disruptive) and status enquiry. Moreover LSP tracing from the source
to the destination (as provided today by a TraceRoute function in
the IP domain) or simply ICMP-like commands must be provided to the
client LSR in order to check the integrity of the connections.
Remember here that LSPs are non-packet LSPs meaning that under
definition MPLS (tunnel) tracing methods are not applicable as such
to verify the status of a connection.
An end-system discovery procedure (also referred to as neighbor
discovery) may be used over the boundary interface (the domain
service interface) to verify local port connectivity between the
optical network and client LSR. Finally, a service discovery
procedure can be executed to obtain details about the connection
services offered by the optical network. The protocol (or
extensions) defined for neighbor discovery purposes are different
from the signaling protocol itself. They can be implemented for
instance through the use of LMP (see [MPLS-LMP]) or BGP (see [RFC-
1771]).
The set of connection services is offered across the domain service
interface such that the signaling protocol must provide a few
messages with certain edge-to-edge dedicated attributes only
significant between the client LSR and the optical network. Such a
protocol can be based on RSVP-TE [MPLS-RSVP] or CR-LDP [MPLS-LDP] as
defined today in [GMPLS-SIG] extended to RSVP-TE [GMPLS-RSVP] and
CR-LDP [GMPLS-CRLDP].
The domain services model does not deal with the type and nature of
routing protocols within the optical network. However, the use of an
IGP routing protocol extended to include Traffic-Engineering
attributes such as [GMPLS-OSPF-TE] and [GMPLS-ISIS-TE] is certainly
the best solution. Furthermore, the integration of multiple, sub-
networks across inter-domain interface could require the
specification of extensions to inter-domain routing protocols such
as BGP. The domain services model would then result in the
Papadimitriou et al. Expires January 2002 6
draft-papadimitriou-enhanced-lsps-04.txt July 2001
establishment of an LSP topology (in the context of this memo,
Lambda-LSP and Fiber-LSP) and between client LSRs located at the
edge of the optical network.
3. Connection Identification
The connection services provided by the optical network are closely
related to the connection end-point identification. The following
LSR interface (referred here to as non-PSC interface) identification
parameters are considered from the client and network perspective.
3.1 Client and Optical LSR Interfaces
An Optical LSR (OLSR) refers to either an Optical Cross-Connect
(OXC) or a Photonic Cross-Connect (PXC) while a Client LSR refers
usually to a router, an SDH/Sonet or an OXC. In the context of this
memo and as usually agreed an OXC is defined as an O-E-O capable
device while a PXC is defined as an O-O capable device.
3.1.1 Non-PSC Interfaces
Optical and Client LSRs include devices where the forwarding
decision is based on time slots, wavelengths, or physical ports. So,
the set of Optical LSRs interfaces is defined as including the
following classes of interfaces in addition to the Packet Switch
Capable (PSC) interfaces and Layer-2 Switch Capable (L2SC)
interfaces:
- Time-Division Multiplex Capable (TDM) interfaces:
Interfaces that forward data based on the data's time slot in a
repeating cycle. Such interfaces belong mainly to SDH/SONET
Cross-Connect (XC), Add-Drop Multiplexer (ADM) and G.709 Cross-
Connect (operating at the Digital Transport Layer).
- Lambda Switch Capable (LSC) interfaces:
Interfaces that forward data based on the wavelength on which the
data is received. Such interfaces belong mainly to Photonic Cross-
Connect (PXC), Optical Cross-Connect (OXC) and G.709 Cross-Connect
operating at the optical channel layer.
- Fiber-Switch Capable (FSC) interfaces:
Interfaces that forward data based on a position of the data in
the real world physical spaces. Such interfaces belong mainly to
(Multi-Service) Cross-Connects capable to switch the content of a
whole fiber.
To each of these interface types corresponds a Label Switched
Papadimitriou et al. Expires January 2002 7
draft-papadimitriou-enhanced-lsps-04.txt July 2001
Path (LSP) type. Consequently, the following LSP types are defined:
TDM-LSP, Lambda-LSP (L-LSP) and Fiber LSP (F-LSP). LSPs can be
established only between, or through, interfaces of the same type.
The concept of nested LSP (LSP within LSP) facilitates building of
an LSP hierarchy. This hierarchy of LSPs can occur on the same
interface or between different interfaces. Therefore nesting can
also occur between interfaces belonging to distinct layers. The
following diagram illustrates the LSP nesting concept and the LSP
hierarchy.
P-LSP P-LSP
| |
| |
V |
+------------+ |
----| LOVC TDM |--------- |
TDM-LSP| +------------+ TDM-LSP | |
--->| HOVC TDM |------ | |
+------------+ | | |
| | | | |
| | V V V
| | +-------------+
TDM-LSP| ------>| LSC |
| +-------------+
| |
V |L-LSP
+------------+ |
| FSC |<---------
+------------+
Needless to say, that this memo is mainly focused on Lambda-LSP (L-
LSP) services either standard (G.709 OTN based) or non-standard
(including pre-OTN developments).
3.1.2 Non-PSC Interfaces Address Space
We consider here that any transport and control addressing scheme
uses IPv4 and/or IPv6 addresses. Other categories of addressing
schemes such as NSAP are not considered in this memo. This because
as described in [GMPLS-ARCH], it would imply a modification of the
already existing signaling and routing protocols (included in the
Generalized MPLS protocol suite) that uses IPv4 and/or IPv6
addresses.
The fact that IPv4 and/or IPv6 addresses are the only considered
doesn't imply at all that they should be allocated in the same
addressing space than public IPv4 and/or IPv6 addresses used for the
Internet.
Papadimitriou et al. Expires January 2002 8
draft-papadimitriou-enhanced-lsps-04.txt July 2001
Each network layer could have a different administrative authority
responsible for address allocation and re-using the full addressing
space, completely independently though this does not seem to be the
most efficient way to allocate and manage the address space(s).
While private IP addresses can be used if they don't require to be
exchanged with any other operator, public IP addresses are otherwise
required.
As part of the Domain Service Model and as described in [IPO-RTG],
reachability information exchange through the Domain Service
interface, using eBGP protocol for instance, is considered as a must
within the scope of this document.
3.1.3 Non-PSC Interface Identifier Space
The following parameters are related to the physical-level
interfaces identification of Client and Optical LSR. Identifier
space value is purely local to each node. Therefore these values are
not used for routing purposes:
- Port ID: integer indicating and identifying a port within an
Optical LSR (OLSR)
- Channel ID: integer indicating and identifying a channel (i.e. a
wavelength) within a given port ID
- Logical-port ID: identifies a logical port whose identifier is
defined as the concatenation of the Port ID and the Channel-ID.
These definitions can be extended to identify the client network
element (client LSR) interfaces also simply referred to as LSR
interfaces.
3.2 Optical Network Identification
The optical network identification parameters can be defined, as a
Carrier Identifier (Carrier ID) is an integer defining the identity
of the carrier to which the OLSR element belongs.
The Carrier ID uniquely determines the owner of a signalling message
when travelling over inter-domain interface signalling channels
between optical networks. Typically the Carrier ID will be assigned
to the BGP AS number (2 bytes).
This identifier is provisioned by the administrative authority of
the optical network and can be exchanged during the neighbor
discovery process or any other inter-domain routing protocol
exchange such as BGP [RFC-1771].
3.3 Client Network identification
Papadimitriou et al. Expires January 2002 9
draft-papadimitriou-enhanced-lsps-04.txt July 2001
The client network identification parameters include additionally to
the Client LSR logical-port ID, the Client Network Identifier
(Client Network ID) and the VPN Identifier (VPN ID):
- Client Network ID: identifier uniquely defining a client network
(or a group of client LSR belonging to the same administrative
authority) with respect to a given optical network domain.
This parameter should not have any complex semantic nor meaning
and could be useful when considering optical broadcast and
multicast applications. The Client Network ID (or simply Client-
ID) will be typically the BGP AS number (2 bytes) of the client
Network or simply the Client device Node ID (for instance, an IPv4
loopback address taken from the public IPv4 address space).
- VPN ID: VPN identifiers as defined in [RFC-2685]
The VPN ID is equivalent to the VPoN ID (Virtual Private optical
Network), however since the corresponding model does not apply
only to optical networks but also to SDH/SONET or any kind of
ôlayeredö transport network, we donÆt refer to VPoN identifiers in
this document.
In absence of a centralized network authority, the source and
destination OLSR are responsible for authentication of VPN IDs and
for call acceptance policies. In the absence of a pre-determined
policy, the default behavior is for the destination client LSR to
accept the LSP create request if the destination client LSR is
part of the signaled and authenticated VPoN.
Since a boundary OLSR can potentially be connected to multiple
client LSR, or a given client LSR can potentially request LSP
for several VPoNs, this identifier defines the possibility to
setup Virtual Private optical Networks (VPoN). The corresponding
models are described in Section 3.4.
The association of the client source address (and by extension the
OLSR address) with the logical-port ID (LPID) is used in the
context of the VPoN model. This implies the VPoNs services are
defined at the optical channel level and not only at the port
level meaning that the granularity of the VPoN can be finer than
the one classically defined for the so-called layer-1 VPNs.
The association of an (Client or OLSR) address and an LPID
<Address;LPID> is referred to as a connection termination-point
identifier (CTID). Typically, the Client and OLSR address space is
IPv4. Mappings between Client and OLSR termination point
identifier [<Client Address;LPID>;<OLSR Address;LPID>] are then
associated through the domain service interface signalling to the
VPN ID to which the LSP connection requests refers. The ingress
(and egress) OLSR need only to maintain a mapping table where this
information is stored per VPN ID. This approach easily provides
Papadimitriou et al. Expires January 2002 10
draft-papadimitriou-enhanced-lsps-04.txt July 2001
VPoN service to the client network.
3.4 VPoN Model
The VPoN - Virtual Private optical Network model considered here are
based on the following concepts:
- the Client ID defines the identification of an optical network
client (for instance, an ISP)
- the VPN ID defines the identification of a group defined
within this optical network client (for instance an ISP client)
The first model considers the Client ID as a VPoN identifier in
addition to the VPN ID while the second one considers only the VPN
ID as a VPoN identifier.
If we consider the Client ID as a VPoN identifier, then the
following alternative could be considered:
- isolation of the resources within a given VPoN (for instance, a
given ISP client)
- isolation of the resources between VPoNs within a given Client-
ID (for instance, between ISP clients belonging to the same
ISP)
- no-isolation of the resources i.e. sharing of the resource
between clients within the optical network
In this example, the optical network has several clients (i.e. ISPs
identified by a unique Client ID) and each of the optical network
clients has several clients (i.e. ISP clients identified by a unique
VPN ID).
If we only consider the VPN ID as a VPoN identifier, then the
following alternative could be considered:
- isolation of the resources within a given VPoN (for instance, a
given ISP)
- no-isolation of the resources i.e. sharing of the resource
between VPoNs within the optical network
In this example, the optical network has several clients (i.e. ISPs
identified by a unique VPN ID) and there is no dependence of the
isolation regarding the owner of the VPoN.
If we consider a unique address space per optical network, it means
that any address belonging to any VPoN must be unique. Otherwise, if
we consider on address space per VPoN (for instance, per Client ID),
then the address uniqueness is limited to this VPoN.
As specified in [RFC-2685], a VPoN may use a private address space,
which may overlap with the address space of another VPN or the
Internet public networks. A VPoN may span multiple optical domains
(BGP AS) meaning that an IP address only has meaning within the VPN
in which it exists. For this reason, it is necessary to identify
the VPoN in which a particular address space is meaningful. Note
Papadimitriou et al. Expires January 2002 11
draft-papadimitriou-enhanced-lsps-04.txt July 2001
also that [RFC-2685] recognized the advantage of identifying any
particular VPoN at any layer and at any location in which it exists
using ideally the same VPoN identifier.
Consequently, the case with address space uniqueness per VPoN is
most flexible since it permits to connect clients having overlapping
address spaces. However, this also requires for the optical network
to maintain a mapping table per VPN ID.
4. Optical Connection Services
Optical Connection Services include LSP Connection Services, LSP
Protection and LSP Routing.
4.1 Basic LSP Connection Services
Basic LSP connection services are provided through the exchange of
the parameters considered within this sub-section. They offer the
possibility to implement the basic connection (i.e. LSP) service
requests through the domain service interface. These parameters are
mainly the framing, the bandwidth, the directionality and the
network protection level.
4.1.1 Framing
The Framing parameter specifies the encoding format of the signal
for the requested connection. The Framing represents the networking
layer at which the requested connection will operate throughout the
optical network.
The Framing-type (referred to as LSP Encoding Type in [GMPLS-SIG])
for LSP established throughout an optical network could be one of
the following:
- Ethernet: LAN Ethernet (LAN PHY) and WAN Ethernet (WAN PHY)
- TDM: SDH (ITU-T G.707) and SONET (ANSI T1.105)
- Digital Wrapper: ITU-T G.709 Digital Path and Proprietary
- Optical: ITU-T G.709 Optical Channels and Non-standard Lambda
4.1.2 Bandwidth
The Bandwidth values are defined with respect to the Framing-type.
Signal Types extend bandwidth values since the latter can take only
discrete values for non-packet LSP: TDM-LSP (i.e. SDH/SONET LSP), L-
LSP (i.e. G.709 Optical Channel LSP). We refer here to [GMPLS-SIG],
[GSMPL-SDH] and [GMPLS-G709] for more details concerning the Signal
Types definition and their respective value space for SDH/SONET and
G.709 OTN.
4.1.3 Directionality
Papadimitriou et al. Expires January 2002 12
draft-papadimitriou-enhanced-lsps-04.txt July 2001
As described in [GMPLS-SIG], bi-directionality of an LSP is defined
by the use of an upstream label within the LSP create request.
4.1.4 Network Protection
Signalling the network protection requested for an L-LSP can be
performed in two ways: either explicitly or implicitly.
1. Explicit Protection indication
The Protection parameter specifies the protection level desired for
the requested LSP inside the optical network (i.e. internal network
protection). Notice that protection at the domain service interface
(source- and destination-side protection) levels is not covered
since the domain service model implies that the protection of the L-
LSP initiated by the client is up to the corresponding networking
layer. The corresponding LSP nesting can be illustrated as follows:
++++++++++++++++++++++++++++++
+ +
C1 ----------- N1 ----- N2 ----- N3 ------------ C2
| -> A + | / \ | + -> A |
| + | / \ | + |
| + | / \ | + |
------------ N4 -------------- N5 -------------
-> B + + -> B
++++++++++++++++++++++++++++++
Protection at the Network layer:
- Client Request: C1 to C2 Protected LSP
- Network Request: Primary LSP using [N1 û N2 û N3]
Secondary LSP using [N1 û N4 û N5 û N3]
Protection at the Client layer:
- Client Request: C1 to C2 LSP (Primary LSP) through path A
- Client Request: C1 to C2 LSP (Secondary LSP) through path B
Several network protection services (or network edge-to-edge LSP
protection) can be defined:
- Extra-Traffic (preemptable)
- Unprotected (default value)
- Re-routing (path-level edge-to-edge restoration)
- Multi-Group Shared Protection M:N (particular case 1:N)
- Group Shared Protection M:N (particular case 1:N)
- Dedicated 1:1 Protection
- Dedicated 1+1 Protection
- Enhanced Protection (ring-based protection)
Related to these protection types and levels, a reversion strategy
could be defined:
- a revertive strategy means that a LSP gets restored
to its original route after a failure has been recovered (or
Papadimitriou et al. Expires January 2002 13
draft-papadimitriou-enhanced-lsps-04.txt July 2001
restored)
- a non-revertive strategy means that a LSP does not
get restored to its original route after a failure has been
recovered (or restored)
The network protection mechanisms are extensively detailed in [IPO-
RES] together with the required signalling protocol extensions.
Enhanced protection (i.e. ring-based protection) concepts and
mechanisms are detailed in [IPO-RFR].
2. Implicit Protection indication
There is another way to specify within a connection service request
the protection level desired; this by indicating the Class of
Service to which the requested LSP belongs. The Class-of-Services
(CoS) are detailed in section 5.4.
4.2 Pre-OTN Connection Service
Pre-OTN LSPs are also referred to as optical SDH/SONET connections.
Since the SDH/SONET parameters applies only to SDH/SONET framing
(i.e. LSP Encoding Type), Pre-OTN connection service includes the
Transparency levels supported by the optical non-transparent network.
Transparency levels currently supported in such optical networks
are:
- Path OH transparency: the network can transparently
transport HOVC/STS-SPE connections (in that case the
corresponding LSP is equivalent to a TDM-LSP)
- Multiplex Section/Line OH (MSOH/LOH) Transparency: the network
can transparently transport MSn/STS-N connections
- Regenerator Section/Section OH (RSOH/SOH) Transparency: the
network can transparently transport STM-N/OC-N connections
(such transparency service is supported by default throughout
G.709 OTN networks)
Semi-transparent levels can also be defined with respect to the
Client Signal; in that case, the network transparency levels are
referred to as OverHead tunneling levels:
- Specific MSOH/LOH bytes Transparency such as MS/Line DCC (D4
- D12) or K1/K2 bytes: the network can non transparently
transport MSn/STS-N connections while keeping the MS/Line DCC
or other MSOH/LOH bytes unchanged
- Specific RSOH/SOH bytes Transparency such as RS/Section DCC (D1
û D3) or J0 bytes: the network can non transparently
transport MSn/STS-N connections while keeping the MS/Line DCC
or other MSOH/LOH bytes unchanged
Such transparency service provides for instance in-fiber/in-band
signalling transport mechanism across the optical network for
SDH/SONET client networks. Consequently, the optical network does
Papadimitriou et al. Expires January 2002 14
draft-papadimitriou-enhanced-lsps-04.txt July 2001
not use anymore the corresponding MSOH/LOH and/or RSOH/SOH overhead
bytes to provide its internal signalling transport mechanism.
4.3 OTN Connection Service
As described in Section 2.1 based, the OTN connection service is
based on the G.709 specification [ITUT-G709]. However, today most of
the client LSR interfaces donÆt support G.709 specification (in
particular when client LSR are routers) so that at the domain
service interface client-to-network interconnection is provided
through the use of Pre-OTN interfaces supporting STM-N/OC-N signals.
The client signal is terminated at the ingress Optical LSR (OLSR)
and then either tunneled or simply continued within the optical
network.
This suggests the definition of an interworking function OTN<->Pre-
OTN at the Domain Service Interface (i.e. ingress and egress OLSR).
GMPLS Signalling for OTN connection service is defined in [GMPLS-
G709]. Such service provides also the full transparency of the
client signal (see Section 4.2).
4.4 All-Optical Connection Service
The distinction between the OTN and the All-Optical connection
service is made for the following reasons. First the OTN compliance
refer to an Optical Transport Hierarchy (OTH) as described in [G709-
FRM]. Then, OTN compliance implies the implementation of intra-
domain optical signal control and monitoring capabilities through a
specific implementation of the control plane using non-associated
overhead at the OTH level.
Therefore, the optical signal control and monitoring capabilities
can be provided either by using the G.709 non-associated OverHead
(naOH) through the Optical Supervisory Channel (OSC) or by using
non-standardized methods. The latter refers to methods using
technology such as optical signal Sub-Carrier Multiplexing (SCM).
More details about this technology are available in [IPO-SCM].
4.4.1 All-optical Connection Service - Overview
When considering a Domain Service Model, the key issue concerning
all-optical connection service is that the client optical signal
must be terminated at the ingress AND at the egress of the optical
domain (which includes only PXC nodes except at the edge interfaces
toward the client network). Otherwise, it would be impossible for
the optical network to control and monitor the connection service
provided to the client network. This independently to the fact that
the client LSR interfaces must be either colored otherwise
wavelength conversion has to be provided at the ingress of the
optical network.
Papadimitriou et al. Expires January 2002 15
draft-papadimitriou-enhanced-lsps-04.txt July 2001
The alternative is to provide all-optical connection services from
the source to the destination client network without terminating the
optical channel at the ingress and egress of the network. However,
such approach requires providing to the client LSR an access to the
optical control plane since clients nodes must now have the
capability to perform their own L-LSP connection management. This
would in turn require the definition of Virtual Private control
Networks (VPcN) in order to guarantee some privacy. Notice here the
difference between a VPoN and VPcN: the VPoN is a private network
defined at the transport plane level while the VPcN is defined at
the control plane level.
4.4.2 All-Optical Connection Parameters
These parameters are related to all-optical networking connection
services. These parameters can be sub-divided into two groups.
First, the ones used to monitor the optical signal quality such as
the Bit Error Rate (BER). Then, the optical parameters used for
optical routing purposes (commonly referred to as optical routing
impairments) such as the Optical Signal-to-Noise Ratio (OSNR),
Polarization Mode Dispersion (PMD).
The optical signal performance monitoring is achieved by measuring
(through methods not defined in this document) the BER. As
parameters, the BER is defined the exponent of the maximum BER
admitted for a given optical signal (default value is zero). Real-
time measurements allow performing signal quality monitoring and
therefore on-line measurements. In turn, this method enables to
determine whether or not the current optical signal quality meets
the optical connection Service Level Specification (SLS).
Concerning optical routing impairments, linear parameters such as
Optical SNR (OSNR) and Polarization Mode Dispersion (PMD) are
considered in [IPO-ORI] for sub-optimal optical routing. Amplified
Spontaneous Emission (ASE) influence the Optical SNR (OSNR), which
determines an upper bound to the maximum number of spans that an L-
LSP can traverse. The PMD determines an upper bound to the maximum
optical span length that an L-LSP can traverse. More details about
optical routing linear impairments can be additionally found in
[IEEE-ORL]. Nevertheless, these linear parameters constitutes a
subset of the optical routing impairments that have to be considered
for Long Haul optical transmission (> 2000 km). We refer to [IPO-
NLRI], where non-linear optical routing impairments are considered.
For non-transparent optical transport networks, one has to take into
account the Jitter parameter in addition to the Bit Error Rate
(BER). This parameter is defined as the maximum jitter admitted for
a given optical signal (default value is zero) also referred to as
Jitter Tolerance. There are currently three types of jitter
specifications:
- jitter tolerance: the peak-to-peak amplitude of sinusoidal
jitter applied on the input signal that causes a 1dB power
Papadimitriou et al. Expires January 2002 16
draft-papadimitriou-enhanced-lsps-04.txt July 2001
penalty
- jitter generation: the process whereby jitter appears at the
output port û transmission û in absence of input jitter
- jitter transfer: a measure of the quantity of input jitter
attenuation with respect to the output signal
5. Enhanced Optical Connection Services
This section covers the connection services such as Optical
Multicast, Waveband Switching, Optical Class-of-Services and VPoN
services.
5.1 Multicast Service
Today, as described in [GMPLS-SIG], an LSP request can translate
either a unidirectional unicast connection or a bi-directional
unicast connection. Optical multicast connection service provides
the capability to establish point-to-multipoint LSPs throughout the
optical network. In this case, the ingress client and optical LSR
could have many destinations in common therefore reducing the number
of wavelengths used per fiber link. Optical multicast is detailed in
[IPO-OMF] as well as the related signalling considerations. We
briefly summarize here the rationale and key associated concepts.
The optical multicast concept can be applied to numerous client-
layer applications covering mainly Optical Broadband applications,
Multimedia, Video and HDTV.
When extended to the optical domain, the multicast concept offers
the following advantages:
- Efficient optical 1+1 (dedicated) protection
- Improved performance (no store and forward) compared to packet-
oriented multicast technology
- Overall network throughput improvement by reducing the number
of wavelengths used per fiber link (i.e. minimizing the overall
bandwidth usage per fiber link)
- Reduction of the total number of transceivers in all-
optical networks.
However, the major drawback to overcome in optical multicast-capable
networks is to compensate the power penalty introduced during the
optical signal splitting. Moreover, the multicast problem in
communication networks is NP-Complete (since described by the
Steiner Tree Problem applied to communication networks).
[IPO-OMF] also extensively details the diverse possibilities that
can be considered to extend the currently defined (or under-
definition) multicast signalling protocols.
5.2 Waveband Switching Service
Papadimitriou et al. Expires January 2002 17
draft-papadimitriou-enhanced-lsps-04.txt July 2001
Waveband Switching refers to the switching of a non-contiguous set
of identical optical channels which are to be routed, switched and
protected as an individual entity. This service can be useful for
inverse multiplexing where high bandwidth client signal is
partitioned into multiple lower rate optical channels. For instance
a 10 Gbps client signal partitioned into four 2.5 Gbps optical
channels. It is desirable that each optical channel use the same
physical resources, with identical propagation delay (if O/E/O
conversion is needed) and protection schemes, thus minimizing the
segmentation and reassembly within the client domain.
Waveband Switching underlying concepts are extensively covered in
[IPO-WBS] where we demonstrate the benefits from the introduction in
optical networks of the optical multi-granularity concept.
LetÆs briefly examine the key drivers and advantages provided by the
waveband switching services. Today, optical switches are able to
handle different switching granularities from wavelength to fiber
and especially wavebands. Taking benefits from these technologies,
switching larger granularities reduce at the same time the
complexity of control operations, the amount of hardware in the
optical layer, and in addition relax some physical constraints.
Gains expected from the approach are partly function of the
efficiency of the grooming of wavelengths into larger granularities.
In particular, intelligent intermediate grooming makes the multi-
granularity concept even more attractive since reducing the required
size of optical switching matrix typically by a factor of two or
more.
Optical switching allows the transmission capacity of point to point
links to scale up to the predicted traffic requirements of multiple
Tbps. Hence the switching capacity of backbone nodes has to scale up
to thousands of Wavelength Switching Capable (WBSC) interfaces. To
overcome the bottleneck of electronic switching, wavelength cross-
connects have been introduced.
Optical switching can also be extended to switch larger
granularities such as bands of wavelengths (also referred to as
wavebands) and fibers (also referred to as spatial switching). By
considering that optical networks will not experience a significant
evolution of their topology properties (connectivity, number of
nodes), these new granularities will easily support the traffic
growth with limited impact on efficiency.
Therefore, the main issue is to find the optimum way to arrange the
spatial distribution of traffic flows on the topology in order to
create connections at the different optical granularities (i.e.
different LSP bandwidth). The intrinsic properties of a typical
backbone network give us good perspectives to achieve the goal of
dynamically creating LSPs at these granularities. The relatively
limited number of nodes (tens of nodes) and the relative small
connectivity (3 to 8 neighbors per node) allow us to assume that
Papadimitriou et al. Expires January 2002 18
draft-papadimitriou-enhanced-lsps-04.txt July 2001
there will be a strong correlation between flows of traffic inside
the network.
In other terms, it means that, assuming an efficient planning,
numerous flows (e.g. STM-N/OC-N or IP flows) have to be processed in
the same way in the nodes. Thus, this should give the opportunity to
establish wavelength, waveband and fiber connections, and process
most of the traffic using optical granularities as large as
possible. This will alleviate some capacity bottlenecks and above
all reduce the network cost.
In [IPO-WBS], we propose to use this concept of multiple optical
granularities in association with grooming strategies and GMPLS
integration requirements. Among possible optical switching
granularities, waveband is an attractive trade-off for foreseen
traffic volumes in next few years and will be particularly
considered in the following.
For this purpose, waveband-switching layer is introduced as an
additional sub-layer between the Lambda and the Fiber layer i.e.
between corresponding Lambda-LSP (wavelength switching) and Fiber-
LSP (spatial switching). However, this sub-layer does not introduce
either a new type of interface or a new class of Forwarding
Adjacencies (FA) class since we consider a Lambda LSP (L-LSP) as a
particular case of a more generic Waveband-LSP (WB-LSP).
In terms of grooming strategies, we also propose to have both end-
to-end and intermediate grooming at waveband and fiber levels to
make the concept more attractive. Intermediate grouping is referred
to as the aggregation of traffic with different source nodes and/or
different destination nodes but with a common sub-path at the
optical layer. End-to-end grooming (i.e. between source and
destination OLSR) is a particular case of intermediate grooming
where the sub-path in the optical layer is the entire Lambda-LSP (L-
LSP) between source and destination OLSR.
5.3 Priority-Preemption
The priority-preemption is a service offering prioritization of the
connection requested during the LSP setup with respect to the
provisioned priorities of the optical network resources (links,
paths, etc.). Then the priority of the connection is used to define
a preemptability level of the connection with respect to the setup
and/or recovery of other LSPs already provisioned or dynamically
established within the optical network.
5.3.1 Priority
The Priority specification (as described in [MPLS-CRLDP] for
instance) includes the setup and the hold priority. The priority
field is defined as an (8-bit) integer indicating the priority of the
requested L-LSP:
Papadimitriou et al. Expires January 2002 19
draft-papadimitriou-enhanced-lsps-04.txt July 2001
- Default value: from 0x<C>E (higher) to 0x<C>1 (lower)
- Priorities from 0x<C>F is reserved
- Priorities from 0x<C>0 is reserved
Where <C> (4 MS bits) defines the priority-class: C ranges from 1 to
E Class 1 is considered as the default class and Class 0 and Class F
are reserved priority-classes. The priority value (4 LS bits) within
a given priority-class ranges from 0xE (higher priority) to 0x1
(lower priority).
5.3.2 Preemption
Preemption is defined as a (4-bit) integer indicating the
preemptability behavior of an L-LSP. This parameter specifies
whether a given LSP can be preempted by a L-LSP of higher priority
if the resource used by the lower-priority L-LSP need to be used
during the setup and/or the recovery of this higher priority L-LSP.
The possible values for the preemption behavior can be defined as:
- Setup and Recovery preemptability: 0x0 (Class 1)
- Recovery preemptability : 0x1 (Class 2 to 7)
- Setup preemptability : 0x2 (Class 8 to D)
- No_preemptability : 0x3 (Class E)
5.4 Class-of-Services
The Class-of-Services (CoS), described in [IPO-COS] and based on
[DIFF-ARCH] specification, are build upon the following principle:
at the (ingress) client LSR, if we consider Packet-Switch
Capable(PSC) interfaces, the DiffServ Codepoint (DSCP) [DIFF-DSF]
defining the Per Hop Behaviour (PHB) [DIFF-PHB], are mapped to the
LSP priority class. For this purpose, we propose the following
rules:
- Class 1 corresponds to Best-Effort service
- Class 2 to D corresponds to Assured Forwarding (AF) services
. Class AF1 ranges from 2 to 4
. Class AF2 ranges from 5 to 7
. Class AF3 ranges from 8 to A
. Class AF4 ranges from B to D
- Class E corresponds to Expedited Forwarding (EF) service
These DiffServ classes are related within the optical network to the
service-level defined in section 3:
- Class 1 defines a best-effort service
- Class 2 to 7 defines a bronze service
- Class 8 to D defines a silver service
- Class E defines a gold service
Within our definition of LSP, the analogy between the drop
precedence in DiffServ and the priority class could also be related
to the preemption setting at the domain service interface during the
Papadimitriou et al. Expires January 2002 20
draft-papadimitriou-enhanced-lsps-04.txt July 2001
LSP creation. In this case, the priority value setting is performed
through the following rules:
- Class 1 defines a priority ranging from 0x11 to 0x1E
- Class 2 to 7 defines a priority ranging from 0x21 to 0x7E
- Class 8 to D defines a priority ranging from 0x81 to 0xDE
- Class E defines a priority ranging from 0xE1 to 0xEE
Application of this model will enable to have a selection mechanism
at the boundary client LSR (in most of the cases, it will be a
router) providing LSP multiplexing based on the mapping between the
DiffServ Code Points (DSCP) and the LSP Class-of-Services provided
by the optical network. Moreover, this technique enables the direct
mapping of finer granularity Packet-based LSP to coarser granularity
L-LSPs without any disruption in the end-to-end QoS offered to the
client network connections.
5.5 VPoN Service
The relationship between the Priority/Preemption and the CoS and
VPoN model is based on the resource isolation concept. Two VPoN
models have been defined (depending on the usage of the Client ID)
so that the Priority/Preemption levels considered here are directly
related to these models and the resource isolation concept.
If we consider the Client ID as an identifier, then we have the
following options concerning the preemption levels:
- preemption within a given VPoN (i.e. within VPoN belonging
to the same optical network client)
- preemption within a given Client ID (i.e. between VPoN
belonging to the same optical network client)
- preemption between Client IDs (i.e. between optical network
clients)
If we do not consider the Client ID as an identifier, then we have
the following options concerning the preemption levels:
- preemption within a given VPoN (i.e. within VPoN belonging
to the same optical network client)
- preemption between VPoNs (i.e. between VPoN belonging to
the separate optical network client)
5.6 LSP Monitoring
TBD.
5.7 LSP Routing Diversity
From the optical network viewpoint, LSP routing diversity is related
to the path disjointness provided by the constraint-based route
computation at the ingress optical LSR. Routing diversity can be
related to link, node, path and Shared Risk Link Group (SRLG). Here,
we focus on the disjointness of the LSP explicit route with respect
to SRLGs.
Papadimitriou et al. Expires January 2002 21
draft-papadimitriou-enhanced-lsps-04.txt July 2001
It is commonly admitted [IPO-FRM] that SRLGs identifiers are
exchanged between nodes belonging to the same optical domain to
prevent the use of shared resources that can affect all links
belonging to this group in case of shared resource failure. For
instance, as described in [IPO-SRLG], two LSPs flowing through the
same fiber link in the same fiber trunk. The SRLG concept has been
extended by demonstrating that a given link could belong to more
than one SRLG, and two links belonging to a given SRLG may
individually belong to two other SRLGs.
Many proposals already include the SRLG concept when considering the
constraint-based path computation of optical channel routes. In
optical domains this concept of SRLG is used for deriving a path,
which is disjoint from the physical resource and logical topology
point-of-view. However, the definition of SRLG in the current format
as described in [GMPLS-OSPF-TE] and [GMPLS-ISIS-TE] does not
provide:
- the relationship between logical structures or physical
resources (for example, a fiber could be part of a sequence of
fiber segments, which is included in a given geographical
region), and
- the risk assessment during path computation implying the
allocation of a conditional failure probabilities with the
SRLGs
- the analysis of the specifications of constraint-based path
computation and path re-optimization taking SRLG information
into account.
The model proposed in [IPO-SRLG] document proposes a technique to
compute the SRLG with respect to a given risk type. This is achieved
by identifying for a given physical layer the resources belonging to
an SRLG. The proposed model also permits to compute the dependencies
of these resources into the resources belonging to lower physical
layers. The result of the computation also enables OLSR to determine
the risk associated to each of the SRLGs.
1. Hierarchical Model
The SRLG model defined in [IPO-SRLG] includes two hierarchies: the
physical hierarchy and the logical hierarchy.
The physical hierarchy is related to the fiber topology (more
generally the physical resources) of the optical network including
the wavelengths build on top of this physical topology. The network
(physical) resource model considered in [IPO-SRLG] is based on
concepts introduced in [IPO-FRM]. The concepts around network
resource hierarchy developed within this document are based on the
following components:
- Sub-Channel (TDM circuit û only applicable for SDH/SONET
networks)
- Optical Channel (or Wavelength)
Papadimitriou et al. Expires January 2002 22
draft-papadimitriou-enhanced-lsps-04.txt July 2001
- Fiber Link
- Fiber Segment
- Fiber Sub-segment
- Fiber Trunks
The Logical hierarchy is related to the geographical topology of the
network. The definition of the logical hierarchical structure covers
an increasing extended logical structure partitioning of the area
covered by the optical network. For that purposes the concept of
node, zone and region are defined in [IPO-SRLG].
2. Risk Assessment
Risk assessment is defined as the evaluation of the potential risk
associated to the inclusion of a given resource (this resource
belongs to a given resource type located within a given logical
structure such as a geographical location). Since the SRLG
computation is performed with respect to a given risk type
associated to a given network resource, a failure probability is
assigned to the network resources instances included within the same
logical structure. So, in the approach described in [IPO-SRLG] there
is a direct mapping between the risk type and the resource type as
well as the failure probability associated to this resource type
within a given logical structure.
3. Inference Model
The model described in [IPO-SRLG] is provided to automate the
discovery of the Shared Risk Link Groups (SRLGs) at a given layer
for a given physical resource type. This resource type could be
located within a given region and OLSR.
Note however, that in the domain service model, when a client OLSR
sends an LSP service request it can only reference about the LSPs it
has already established. Consequently, it can only reference an LSP
M from which the new LSP N should be diverse. The OLSR will
interpret this request by considering the Shared Risk Link Group
(SRLG) of the LSP M and find a physical route for the LSP N whose
SRLG is diverse from.
The same process applies at the inter-domain interface where the
outgoing OLSR (belonging to the BGP AS[i]) does only knows about the
LSPs he has already established to the incoming OLSR (belonging to
the BGP AS[j], AS[i] =/= AS[j]). Consequently, the outgoing OLSR can
only reference an LSP M from which the new LSP N should be diverse.
6. Connection Service Policy
Policy-related parameters are related to directory services provided
to the client client LSR through the domain service interface
services. These parameters include the following items:
- Service-Level parameters
Papadimitriou et al. Expires January 2002 23
draft-papadimitriou-enhanced-lsps-04.txt July 2001
- Schedule parameters
- Contract parameters
- Billing parameters
- Optional parameters
By receiving such kind of parameters the source boundary OLSR needs
to forward the content of these request through the NMI interface
(interface between the OLSR and a management server) to a
centralized directory service or de-centralized service in
combination with a distributed connection admission control.
6.1 Service-level Specification
Service level (i.e. service-level specification) parameter could be
implemented as a 16-bit integer which refer to parameters detailed
in the previous sub-section (service-related parameters). This
parameter indicates the class-of-service offered by the optical
network carrier.
The first 256 values (0 û 255) are reserved for future inter-
operability agreements between carriers and service providers. The
remaining values are carrier specific.
The service-level parameter could include the following attributes:
- Optical Signal Quality
- Protection parameters
- Priority and Preemption
- Routing parameters
- Signaling security levels
For instance, value 0x1x might indicate through a request to a
directory service, a best-effort service:
- unprotected LSP
- default priority
- no routing diversity
- no signalling authentication
Value ranging from 0x2x to 0x7x to might indicate through a request
to a directory service, a bronze service:
- M:N protected LSP
- low-priority
- no routing diversity
- signalling authentication (no signalling encryption)
Value ranging from 0x8x to 0xDx to might indicate through a request
to a directory service, a silver service:
- M:N protected LSP
- medium-priority
- no routing diversity
- signalling authentication (no signalling encryption)
Papadimitriou et al. Expires January 2002 24
draft-papadimitriou-enhanced-lsps-04.txt July 2001
Value 0xEx might indicate through a request to a directory service,
a gold service:
- 1:1 protected LSP
- high-priority
- global routing diversity
- signalling authentication and encryption
The optical signal quality levels need to be defined while a low
signal quality does not have to necessarily correspond to a Best-
Effort service.
Consequently, this means that the client knows the meaning of the
service-level prior to the corresponding LSP service request. Within
the LSP request, explicit parameter values take precedence over
service-level.
The definition of the corresponding mechanisms lead us to two
options that seems feasible for this purpose:
- either the client LSR knows the content of the policy-related
parameters without any additional information coming from the
optical network
- or the client LSR initiates an LSP service request (or
even a dedicated request) with appropriate extensions to
request the policy-related parameters values to the optical
network. So the client learns dynamically the service-level
offered by the optical network through a directory service
before initiate a LSP create request to the ingress OLSR. In
future release of this memo, we will refer to this as Service
Discovery Service (SDS) at the domain service interface.
6.2 Scheduling Service
Scheduling refers to the possibility to create, delete or modify LSP
through a given time-of-day, day-to-day, day-to-week, etc.
scheduling plan.
For a given plan, the scheduling functions could be start, stop and
repeat. The attributes of these scheduling functions could be:
- the start/stop time at which the function has to be
executed/stopped
- the start/stop date at which the function has to be
executed/stopped
- the recurrence interval between two repeated execution of the
function
- the number of recurrence intervals
The default values of the schedule parameter regarding the LSP
requested service:
- the start time is the current time (start now)
- the start date is the current date (start now)
- the recurrence interval is infinite since the LSP request has
Papadimitriou et al. Expires January 2002 25
draft-papadimitriou-enhanced-lsps-04.txt July 2001
to be executed only once
- the number of recurrence intervals equals zero
6.3 Billing Service
The billing parameter refers to the billing client identifier onto
which the requested services will be charged. A given client ID
could have more than one billing client identifier.
An optical network client (identified by a Client ID) could have
several clients (i.e. VPN IDs) and assign to each of them a
dedicated billing identifier.
This parameter is implemented as a 16-bit integer. The first 256
values (from 0 to 255) are reserved for future inter-operability
agreements. The remaining values are carrier specific so left with
unspecified semantic.
7. Security Considerations
By including within the service-level parameter the signalling
security level, the proposed document, as detailed in section 6,
takes into account the security of the client signalling request
in a build-in manner.
8. Acknowledgments
The authors would like to thank Bernard Sales, Emmanuel Desmet,
Hans De Neve, Fabrice Poppe, Stefan Ansorge and Gert Grammel for
their constructive comments and inputs.
9. References
1. [DIFF-DSF] S.Nichols et al., æDefinition of the Differentiated
Services Field (DS Field) in the IPv4 and IPv6 HeadersÆ, RFC 2474,
December 1998.
2. [DIFF-ARCH] S.Blake et al., æAn Architecture for Differentiated
ServicesÆ, RFC 2475, December 1998.
3. [G709-FRM] A.Bellato, D.Papadimitriou, et al., æGeneralized MPLS
Control Framework for G.709 Optical Transport NetworksÆ, Internet
Draft, Work in progress, draft-bellato-ccamp-g709-framework-00.txt,
June 2001.
4. [GMPLS-ARCH] E.Mannie et al., æGeneralized MPLS ArchitectureÆ,
Internet Draft, Work in progress, draft-ietf-ccamp-gmpls-
architecture-00.txt, June 2001.
5. [GMPLS-CRLDP] P.Ashwood-Smith, L.Berger et al., æGeneralized MPLS
û Signaling Functional DescriptionÆ, Internet Draft, Work in
progress, draft-ietf-mpls-generalized-cr-ldp-03.txt, May 2001.
Papadimitriou et al. Expires January 2002 26
draft-papadimitriou-enhanced-lsps-04.txt July 2001
6. [GMPLS-G709] M.Fontana, D.Papadimitriou, et al., æGeneralized MPLS
Control for G.709 û Functional DescriptionÆ, Internet Draft, Work in
progress, draft-fontana-ccamp-gmpls-g709-00.txt, June 2001.
7. [GMPLS-ISIS-TE] K. Kompella et al., æIS-IS Extensions in Support
of MPL(ambda)S,Æ Internet Draft, draft-ietf-isis-gmpls-extensions-
01.txt, March 2001.
8. [GMPLS-OSPF-TE] K. Kompella et al., æOSPF Extensions in Support
of MPL(ambda)S,Æ Internet Draft, draft-kompella-ospf-gmpls-
extensions-01.txt, February 2001.
9. [GMPLS-RSVP] P.Ashwood-Smith, L.Berger et al., æGeneralized MPLS û
Signaling Functional DescriptionÆ, Internet Draft, Work in progress,
draft-ietf-mpls-generalized-rsvp-te-03.txt, May 2001.
10. [GMPLS-SIG] P.Ashwood-Smith, L.Berger et al., æGeneralized MPLS -
Signaling Functional DescriptionÆ, Internet Draft, Work in progress,
draft-ietf-mpls-generalized-signalling-04.txt, March 2001.
11. [GMPLS-SDH] E.Mannie et al., æGeneralized MPLS Extensions for
SONET and SDH ControlÆ, Internet Draft, Work in progress, draft-ietf-
ccamp-gmpls-sonet-sdh-01.txt, June 2001.
12. [IPO-COS] D.Papadimitriou et al., æOptical Class-of-Services for
Lambda LSPÆ, Internet Draft, Work in Progress, draft-papadimitriou-
ipo-lambda-lsp-cos-00.txt, July 2001.
13. [IPO-FRM] B.Rajagopalan, J.Luciani et al., æIP Optical
Frameworkö, Internet Draft, Work in Progress, draft-many-optical-
framework-03.txt, March 2001.
14. [IPO-NLRI] D.Papadimitriou et al., æOptical Non-Linear Routing
Impairments in Wavelength Switched Optical NetworksÆ, Internet
Draft, Work in progress, draft-papadimitriouùipo-non-linear-
impairmnets-00.txt, July 2001.
15. [IPO-OMF] D.Papadimitriou, D.Ooms and J.Jones, æOptical
Multicast û A FrameworkÆ, Internet Draft, Work in progress, draft-
poj-optical-multicast-01.txt, July 2001.
16. [IPO-RES] J.Hahm, D.Griffith, R.Hartani and D.Papadimitriou,
æRestoration Mechanisms and Signalling Extensions in Optical
NetworksÆ, Internet Draft, Work in progress, draft-many-optical-
restoration-01.txt, July 2001.
17. [IPO-RFR] H.Ghani, P.Bonenfant, D.Papadimitriou and
S.Dharanikota, æOptical Architectural Framework for Automatic
Protection Provisioning In Dynamic Optical RingsÆ, Internet Draft,
Work in progress, draft-ghani-optical-rings-01.txt, March 2001.
Papadimitriou et al. Expires January 2002 27
draft-papadimitriou-enhanced-lsps-04.txt July 2001
18. [IPO-SCM] D.Blumenthal et al., æOptical Performance Monitoring
in Reconfigurable WDM Optical Networks Using Sub-Carrier
MultiplexingÆ, Journal of Lightwave Technology, Volume 18, Number
12, December 2000.
19. [IPO-SRLG] D.Papadimitriou et al., æInference of Shared Risk
Link GroupsÆ, Internet Draft, Work in progress, draft-many-
inference-srlg-01.txt, July 2001.
20. [IPO-WBS] E.Dotaro et al., æOptical Multi-Granularity û
Architectural FrameworkÆ, Internet Draft, Work in progress, draft-
dotaro-ipo-multi-granularity-00.txt, July 2001.
21. [RFC-1771] Y.Rekther et al., æA Border Gateway Protocol 4 (BGP-
4)Æ, Internet Standard Track, RFC 1771.
22. [RFC-2685] B.Fox and B.Gleeson, æVPN IdentifiersÆ, Internet
Standard Track, RFC 2685.
10. Author's Addresses
Dimitri Papadimitriou (Editor)
Senior R&D Engineer û Optical Networking
Alcatel IPO NSG-NA
Francis Wellesplein 1,
B-2018 Antwerpen, Belgium
Phone: +32 3 240-84-91
Email: Dimitri.Papadimitriou@alcatel.be
Jim Jones
Alcatel TND-USA
3400 W. Plano Parkway,
Plano, TX 75075, USA
Phone: +1 972 519-27-44
Email: Jim.D.Jones1@usa.alcatel.com
Papadimitriou et al. Expires January 2002 28
draft-papadimitriou-enhanced-lsps-04.txt July 2001
Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Papadimitriou et al. Expires January 2002 29