Network Working Group D. Papadimitriou
Document: draft-papadimitriou-enhanced-lsps-02.txt J. Jones
Category: Internet Draft Alcatel
Expiration Date: August 2001
February 2001
Enhanced LSP Services
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
This document describes the LSP parameters and attributes as well as
the enhanced services they support. In the scope of the domain
service model, the main objective of this proposal is to integrate
within these parameters the Optical Multicast concept, the Shared
Risk Link Group (SRLG) Inference model, the Virtual Private optical
Network (VPoN) model, the Class-of-Priorities and the Class-of-
Service (CoS) augmented model; but also enhanced protection and
restorations mechanisms (in optical meshed networks) as well as
signalling security levels. This draft covers the User-to-Network
Interface (UNI) parameters and the specific parameters used within
Network-to-Network Interface (NNI) signalling. In order to structure
these services, we also propose to group the corresponding
parameters in three distinct groups: LSP Identification parameters,
LSP Service parameters and Policy parameters.
Papadimitriou et al. Expires August 2001 1
draft-papadimitriou-enhanced-lsps-02.txt February 2001
1. Introduction
Current IP protocols extensions for services (Integrated or
Differentiated), for traffic-engineering (Multi-Protocol Label
Switching), for privacy (Virtual Private Networks), for multicast
applications (IP Multicast protocols) and for security (IPSec
Protocol) results 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 proposal is to include within the LSP
parameters used within signalling and routing protocols the Virtual
Private optical Network (VPoN) model, the Class-of-Priorities (CoP)
and the Class-of-Service (CoS) augmented model and the optical
multicast trees. Enhancement considered in this document cover also
the protection/restoration and fault-tolerance mechanisms as well as
signalling security levels.
In order to structure the integration of these features within the
signalling and routing protocols, we propose a classification
separating the parameters distributed within an optical sub-network
(Identification and Service parameters) from the one centralized on
directory service (Policy-related parameters). 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 which could in
turn increase the setup time of a LSP.
The remainder of the document is organized as follows:
Sections 2 û 4 describe the details of the attributes for
Identification, Service and Policy groups, respectively. Section 5
describes result and status codes. Annex 1 defines the terminology
used in the contribution.
Note that from the previous version of this memo, we remove the
parameter values already defined in other IETF drafts, in particular
[GMPLS-RSVPTE] and [GMPLS-CRLDP].
2. Identification parameters
The following identification-related parameters are considered.
2.1 Connection termination-point identification parameters
Papadimitriou et al. Expires August 2001 2
draft-papadimitriou-enhanced-lsps-02.txt February 2001
Within the scope of the Domain Service model, the concepts developed
within this section are also related to the address registration and
allocation mechanisms.
2.1.1 Parameters definition
The following identification parameters are related to the physical-
level interfaces of an Optical Network Element (ONE):
- Port ID: integer indicating and identifying a port within an
Optical Network Element (ONE)
- Channel ID: integer indicating and identifying a channel within
a given port ID
- Sub-Channel ID: integer indicating a sub-channel within a given
Channel ID
- Logical-port ID: identifies a logical port; concatenation of the
port-ID, the Channel-ID and the Sub-channel-ID.
The Logical-port ID is not used anymore in [OIF2000.125.3], however
the concept to which it refers is still valid and might be useful
for next developments.
Two types of addresses have been defined the Client Optical Network
Administered Address (ONA Address) and the Optical Network Element
(ONE) Address. Currently, their values are defined as IPv4
addresses.
For more details about the related concepts (address registration
and allocation mechanisms) we refer to [OIF2001.119] and
[OIF2001.121].
2.2 Optical network identification parameters
- The Carrier ID (CID) is an integer defining the identity of the
carrier to which the ONE element belongs.
- The Privacy ID (PrID) determines whether a UNI or a NNI interface
is untrusted (i.e. public) or trusted (i.e. private). Hence, from
this point-of-view, we consider four types of interfaces: trusted
UNI, untrusted UNI, trusted NNI and untrusted NNI interfaces.
These identifiers are provisioned by the administrative authority of
the optical network and are exchanged during the neighbor identity
discovery process as described in [IPO-ONNI].
The Carrier ID uniquely determines the owner of a signalling message
when travelling over inter-domain NNI signalling channels between
optical networks.
Papadimitriou et al. Expires August 2001 3
draft-papadimitriou-enhanced-lsps-02.txt February 2001
The Privacy ID makes the distinction between trusted and untrusted
NNI interfaces. Generally, there is a trust relationship between
intra-domain NNI interfaces and an untrusted relationship between
inter-domain NNI interfaces.
2.3 Client identification parameters
2.3.1 Parameters definition
The client identification parameters include the Client Identifier
(Client ID) and the VPN Identifier (VPN ID).
- Client ID: 32-bit integer (provided by the client) which
uniquely identifies a client (i.e. a group of client CNE belonging
to the same administrative authority) against the optical network
domain.
This parameter should not have any complex semantic nor meaning
and could be useful when considering optical broadcast and
multicast applications.
Note that the client identifier is not equivalent to the
Contract ID parameter defined in [OIF2000.61.6] and [IPO-UNIR].
In this proposal, the Contract ID parameter is defined in section
4.3.
- VPN ID: 7-bytes field structure based on the VPN identifiers as
defined in [VPN-ID]
The source and destination ONE 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 CNE to accept the LSP create request if the
destination CNE is part of the signaled and authenticated VPN.
Since a boundary ONE can potentially be connected to multiple
client CNEs, or a given client CNE can potentially request LSP
for different VPNs, this identifier defines the possibility to
setup Virtual Private optical Networks (VPoN). The corresponding
models are described in the next section.
2.3.2 VPoN Models
The VPoN - Virtual Private optical Network models 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)
Papadimitriou et al. Expires August 2001 4
draft-papadimitriou-enhanced-lsps-02.txt February 2001
The first model considers the Client-ID as a potential VPoN
identifier in addition to the VPN ID and the second one considers
only the VPN ID as a VPoN identifier.
If we consider the Client-ID as a potential 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 potential 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.
2.3.3 VPoN and Address Space Uniqueness
If we consider one unique address space per optical network, this
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 [RFC2547], 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
also that [RFC2547] 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 second case is most flexible since it permits to
connect client having overlapping address spaces. However, this also
requires for the optical network to maintain one mapping table per
Client ID.
Papadimitriou et al. Expires August 2001 5
draft-papadimitriou-enhanced-lsps-02.txt February 2001
2.4 LSP identification parameters
The LSP Identifier (LSP ID) is the unique identifier of the LSP
assigned by the optical network. The LSP ID is coded as a 64-bit
field obtained from the concatenation of two fields uniquely
identifying the LSP within an optical network:
- IPv4 address of the source ONE considered as an unique IP address
inside a given optical network
- An integer assigned by the source ONE that is locally unique
within a given ONE
LSP ID is assigned by the source ONE in response to a LSP
create request. Within the LSP create message (sent by the client
CNE), the UNSPECIFIED value is assigned to the LSP ID.
However, an additional distinction could be suitable when
considering untrusted interfaces. In this case, the Carrier ID
replaces the IPv4 address in order to hide the ONE identifier (ONE
IPv4 address) from the client network.
LSP ID reserved values could be defined as follows:
- UNSPECIFIED value: 0x0...0 referring to a not-specified LSP ID
- ALL value: 0xF...F referring to all the LSP IDs
3. Services parameters
Concerning the LSP services, the basic LSP services, the LSP
protection and LSP routing parameters are considered.
3.1 LSP services parameters
The parameters considered within this sub-section, offers the
possibility to implement the enhanced services proposed as main
objective of this proposal.
3.1.1 Framing-Bandwidth
The Framing-Bandwidth parameter is defined as an integer specifying
the format and the associated bandwidth of the signal transported
across the UNI and represents the framing and bandwidth of the
service requested through the optical network.
The Framing-type (or LSP Encoding Type [GMPLS-SIG]) possible values
are defined as follows:
- Sonet
- SDH
- Ethernet
- Digital Wrapper
- Clear Channels
Papadimitriou et al. Expires August 2001 6
draft-papadimitriou-enhanced-lsps-02.txt February 2001
The Bandwidth possible values are defined with respect to the
Framing-type where the SONET/SDH framing includes the overhead
termination types:
- SONET Framing:
Possible values are OC-<N> where N = 1 (OC-1) to 3072 (OC-3072)
Or encoded as explicit discrete values VT1.5, VT2, VT3, VT6,
OC-1, OC-3c, OC-12c, OC-48c, OC-192c, OC-48 Line, OC-48
Section, OC-192 Line, OC-192 Section.
- SDH Framing:
Possible values are coded as STM-<N> where N = 1 (STM-1) to
N=1024 (STM-1024)
Or encoded as explicit discrete values VC-11, VC-12, VC-2, VC-3,
VC-4, VC-4-4c, VC-4-16c, VC-4-64c, MS-16, MS-64, RS-16, RS-64
- Ethernet Framing:
Possible values are 10Mbps, 100Mbps, 1 Gbps and 10 Gbps
- Digital Wrapper:
Possible values are 2.5 Gbps, 10 Gbps and 40 Gbps
Note: Digital Wrapper refers to Standard Digital Wrapper layer as
proposed by the ITU-T G.709 v0.83 recommendation which has
been integrated within GMPLS Signalling in [GMPLS-G709].
- Clear Channels (Photonic channels): possible values are OC-<N>
where N = 0x001 (OC-1) to N = 0xC00 (OC-3072)
3.1.2 SDH/Sonet Connection Service
The SDH/Sonet parameter applies only to SDH/Sonet framing (i.e. LSP
Encoding Type). This parameter includes the Transparency levels and
the Concatenation types.
Transparency value could take one of the following values:
- No transparency - Default-value
- Regeneration section/Section OH (RSOH/SOH) bytes Transparency
- RSOH/SOH and Multiplex Section/Line OH (MSOH/LOH) Transparency
- Specific OH bytes Transparency such as J0, K1/K2, etc.
In PLR-Circuits, all SDH/Sonet overhead bytes are left unchanged
when transported between clients over the optical network. STE-
Circuits preserves all SDH/Sonet Line overhead bytes between clients
but the section overhead bytes are not required to be preserved.
LTE-Circuits preserves the SDH/Sonet payload but the Section and
Line overhead bytes are required to be preserved. However, as
proposed here above, a finest granularity (per overhead byte and on-
demand) transparency should be defined in order to cover the current
equipment needs.
Papadimitriou et al. Expires August 2001 7
draft-papadimitriou-enhanced-lsps-02.txt February 2001
Concatenation could take one of the following values:
- Default-value (no concatenation)
- Virtual Concatenation
- Standard Contiguous Concatenation
- Arbitrary Contiguous Concatenation
More details concerning the emulated Transparency and Concatenation
could be found in [GMPLS-SDH], [GMPLS-G709] and [GMPLS-SIG].
3.1.3 All-Optical Connection Service
The optical parameter is related to all-optical network. Since
SDH/Sonet framing is currently the key consideration, this parameter
should be not included within the LSP service requests (even
optionally).
This parameter is divided in two parts; both defines the maximum
admitted value for an optical signal technology-related parameter:
- Bit Error Rate: integer defining the exponent of the maximum BER
admitted for a given optical signal (default value is zero)
- Jitter: integer defining the maximum jitter admitted for a given
optical signal (default value is zero) also referred to as jitter
tolerance
As currently defined in optical transport systems, there are 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 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
- Propagation Delay: integer specifying an upper limit for the
maximum acceptable propagation delay (units in microseconds)
acceptable for the optical signal. The default value of the
Propagation Delay is infinite. The Propagation Delay parameter can
be used as an additive metric (or additive weighted metric) for
constraint-based path computation.
Other optical physical-level parameters can be defined as OSNR and
PMD. Up to now, the need of optical parameter during the lightpath
creation process is not needed but future packet-over-wavelength
switched networks might rapidly evolve such that this parameter
becomes mandatory.
3.1.4 Connection Directionality and Multicast Service
The directionality parameter is an integer indicating the
directionality of the LSP. If this optional parameter is omitted,
Papadimitriou et al. Expires August 2001 8
draft-papadimitriou-enhanced-lsps-02.txt February 2001
the LSP is assumed to be bi-directional. However, as described in
[GMPLS-SIG], bi-directionality of an LSP is implicitly defined by
the use of a suggested label within the LSP create request.
Possible values are: - unidirectional
- bi-directional (default value)
- multi-directional (optical multicast)
Multi-directionality concept is related to point-to-multipoint LSPs
established throughout the optical network. In this case, one source
could have many destinations. Optical multicast is detailed in [IPO-
MULT] as well as the related signalling considerations.
- Multicast Service û
As described in [IPO-MULT], the optical multicast concept can be
applied to numerous client- layer applications covering Optical
Storage Area Networks (O-SAN), Optical Broadband Multimedia (for
instance, video and HDTV), etc.
Optical multicast offers advantages in the following critical
aspects of all-optical networks:
- Efficient optical (1+1) all-optical protection
- Improved performance (no store and forward) compared to packet-
oriented multicast technology
- Reduction of the total number of transceivers in the all-optical
network.
- Overall network throughput improvement by reducing the number of
wavelengths used per fiber link (i.e. minimizing the overall
bandwidth usage per fiber link)
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 (described by the Steiner Tree Problem and
applied to communication networks) is NP-Complete.
[IPO-MULT] also describes the diverse possibilities that can be used
to extend the currently defined (or under-definition) multicast
signalling protocols.
3.1.5 Priority-Preemption and CoS Augmented Model
The priority-preemption is an optional parameter defined as a 16-bit
integer including the setup priority (8-bit integer field) and the
hold priority (8-bit integer field) and preemption level (8-bit
integer field) of an LSP.
1. Priority
The Priority specification (as described in [MPLS-CRLDP]) includes
Papadimitriou et al. Expires August 2001 9
draft-papadimitriou-enhanced-lsps-02.txt February 2001
the setup and the recovery priority. The corresponding encoding is
defined as a 8-bit integer indicating the priority of
the LSP:
- 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 (8 LS bits) within
a given priority-class ranges from 0xEE (higher priority) to 0x11
(lower priority).
2. Preemption
Preemption is a 4-bit integer indicating the preemptability of an
LSP. This parameter specifies whether a given LSP can be preempted
by a LSP of higher priority if the resource used by the lower-
priority LSP need to be used during the setup and/or the recovery of
this higher priority LSP.
The possible values for the preemption (4 MS bits û 4 LS bits are
reserved for future use) are:
- Setup and Recovery preemptability: 0x00 (Class 1)
- Recovery preemptability : 0x10 (Class 2 to 7)
- Setup preemptability : 0x20 (Class 8 to D)
- No_preemptability : 0x30 (Class E)
3. CoS Augmented Model
The CoS augmented model, described in [IPO-COS] and based on [DIFF-
ARCH] specification, is build upon the following principle: at the
boundary CNE, 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
Papadimitriou et al. Expires August 2001 10
draft-papadimitriou-enhanced-lsps-02.txt February 2001
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 UNI during the LSP creation. In
this case, the priority value setting is performed through the
following rules:
- Class 1 defines a priority ranging from 0x110 to 0x1EF
- Class 2 to 7 defines a priority ranging from 0x210 to 0x7EF
- Class 8 to D defines a priority ranging from 0x810 to 0xDEF
- Class E defines a priority ranging from 0xE10 to 0xEEF
Application of this model will enable to have a selection mechanism
at the boundary CNE (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 service class within the optical
network. This technique enables the direct mapping of finer
granularity Packet-based LSP to coarser granularity Lambda-switched
LSPs without any disruption in the end-to-end QoS offered to the
client layer networks.
4. VPoN Model
The relationship between the Priority/Preemption and the CoS and
VPoN model is based on the resource isolation concept described in
section 2.3. Two VPoN models have been defined (using the Client ID
or not, respectively), 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 a potential 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 a potential 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)
3.1.6 Bundles
The corresponding encoding and semantic is left for further study.
Note the concept has been considered in [IPO-BUNDLE] and [GMPLS-
BUNDLE].
3.2 LSP protection parameters
Papadimitriou et al. Expires August 2001 11
draft-papadimitriou-enhanced-lsps-02.txt February 2001
Protection parameter indicates the protection level desired for the
LSP inside to the optical network (internal protection) or at the
UNI (source- and destination-side protection levels) which the
protection level requested between both side of the client-to-
network connection.
This optional parameter indicates the location (i.e. the scope) of
the protection requested by the client device:
- the optical network: internal network protection
- the source drop-side: source-side protection
- the destination drop-side: destination-side protection
- no protection (default-value)
For each of these protection types, the protection levels (8-bit
integer) defined are the following:
- Internal Protection (or Network path-level protection):
. Unprotected (default value)
. Dedicated 1+1 Protection
. Dedicated 1:1 Protection
. Shared Protection M:N (particular case 1:N)
. Enhanced Protection (ring-based protection)
. Restoration (path-level re-routing)
- Source-Side Protection (protection between CNE and ONE on source
side):
. Unprotected (default value)
. Dedicated 1+1 Protection
. Dedicated 1:1 Protection
. Shared Protection M:N (particular case 1:N)
. Enhanced Protection (ring-based protection)
- Destination-Side Protection (protection of between CNE and ONE on
destination side):
. Unprotected (default value)
. Dedicated 1+1 Protection
. Dedicated 1:1 Protection
. Shared Protection M:N (particular case 1:N)
. 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
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.
Papadimitriou et al. Expires August 2001 12
draft-papadimitriou-enhanced-lsps-02.txt February 2001
3.3 LSP routing parameters
LSP routing parameters are from one side related to the path
disjointness during the CSPF route computation and from the other
side related to constraint-based routing (explicit and record route
concepts).
3.3.1 Routing Diversity
The routing diversity service is based on the Shared Risk Link Group
(SRLG) concept. It is commonly admitted [IPO-FRAME] and [IPO-BUNDLE]
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. [IPO-BUNDLE]
extends the SRLGs concept 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] and [GMPLS-ISIS] 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 one 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
Papadimitriou et al. Expires August 2001 13
draft-papadimitriou-enhanced-lsps-02.txt February 2001
concepts introduced in [IPO-FRAME]. 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)
- Channel (or Wavelength)
- 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 zone.
Note however, that in the domain service model, when a client ONE
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 ONE 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 NNI interface where the
outgoing ONE (belonging to the BGP AS i) does only knows about the
LSPs he has already established to the incoming ONE (belonging to
the BGP AS j). Consequently, the outgoing ONE can only reference a
LSP M from which the new LSP N should be diverse.
3.3.2 Explicit Route
Papadimitriou et al. Expires August 2001 14
draft-papadimitriou-enhanced-lsps-02.txt February 2001
Explicit route parameter applies only at the NNI. However, this
parameter could be used at the UNI within the scope of the Domain
Specific Routing model. The semantic of the explicit route parameter
for optical networks is detailed in [IPO-ONNI].
3.3.3 Record Route
Record route parameter applies only at the NNI. However, this
parameter could also be used at the UNI within the scope of the
Domain Specific Routing model. The semantic of the record route
parameter for optical networks is detailed in [IPO-ONNI].
4. Policy parameters
Policy-related parameters are related to directory services provided
to the client CNE through the UNI services. These parameters include
the following items:
- Service-Level parameters
- Schedule parameters
- Contract parameters
- Billing parameters
- Optional parameters
By receiving such kind of parameters the source boundary ONE needs
to forward the content of these request through the NMI interface
(interface between the ONE and a management server) to a centralized
directory service or de-centralized service in combination with a
distributed connection admission control.
4.1 Service-level parameters
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:
- Priority and Preemption
- Propagation Delay
- Protection parameters
- Routing parameters
- Signaling security levels
For instance, value 0x1xxx might indicate through a request to a
directory service, a best-effort service:
- unprotected LSP
Papadimitriou et al. Expires August 2001 15
draft-papadimitriou-enhanced-lsps-02.txt February 2001
- default priority
- infinite propagation delay
- no routing diversity
- no signalling authentication
Value ranging from 0x2xxx to 0x7xxx to might indicate through a
request to a directory service, a bronze service:
- M:N protected LSP
- low-priority
- infinite propagation delay
- no routing diversity
- signalling authentication (no signalling encryption)
Value ranging from 0x8xxx to 0xDxxx to might indicate through a
request to a directory service, a silver service:
- M:N protected LSP
- medium-priority
- infinite propagation delay
- no routing diversity
- signalling authentication (no signalling encryption)
Value 0xExxx might indicate through a request to a directory
service, a gold service:
- 1:1 protected LSP
- high-priority
- finite propagation delay
- global routing diversity
- signalling authentication and encryption
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.
4.2 Schedule parameters
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 the scheduling function 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
Papadimitriou et al. Expires August 2001 16
draft-papadimitriou-enhanced-lsps-02.txt February 2001
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
to be executed only once
- the number of recurrence intervals equals zero
4.3 Contract parameters
The contract parameter is defined as an identifier (Contract ID)
whose value corresponds to a string defined in [OIF2000.61.5]. The
semantic proposed for this parameter refers to the policy parameters
defined in this section. Note that a given Client ID could have more
than one Contract ID.
4.4 Billing parameters
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 (a Client ID) may 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 (0 û 255) are reserved for future inter-operability
agreements. The remaining values are carrier specific.
4.5 Optional parameters
Optional parameters could include Vendor-specific parameters, etc.
The definition of the corresponding mechanisms lead us to two
options that seems feasible for this purpose:
- either the client CNE knows the content of the policy-related
parameters without any additional information coming from the
optical network
- or the client CNE 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
ONE. In future release of this memo, we will refer to this as
service discovery service (SDS) at the UNI.
5. Security Considerations
By including within the service-level parameter the signalling
Papadimitriou et al. Expires August 2001 17
draft-papadimitriou-enhanced-lsps-02.txt February 2001
security level, the proposed document, as detailed in section 4,
takes into account the security of the client signalling request
in a build-in manner.
6. 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.
7. 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. [GMPLS-SIG] P.Ashwood-Smith et al., æGeneralized MPLS - Signaling
Functional DescriptionÆ, Internet Draft, draft-ietf-mpls-
generalized-signalling-01.txt, November 2000.
4. [GMPLS-CRLDP] P.Ashwood-Smith et al., æGeneralized MPLS û
Signaling Functional DescriptionÆ, Internet Draft, draft-ietf-
mpls-generalized-rsvp-te-00.txt, November 2000.
5. [GMPLS-G709] M.Fontana and D.Papadimitriou, æGeneralized MPLS
Control for G.709 û Functional DescriptionÆ, Internet Draft,
draft-fontana-gmpls-control-g709-00.txt, February 2001.
6. [GMPLS-RSVPTE] P.Ashwood-Smith et al., æGeneralized MPLS û
Signaling Functional DescriptionÆ, Internet Draft, draft-ietf-
mpls-generalized-cr-ldp-00.txt, November 2000.
7. [IPO-COS] D.Papadimitriou et al., æOptical Class-of-Services û An
Augmented ApproachÆ, Work in Progress, draft-papadimitriou-ipo-
cos-00.txt, February 2001.
8. [IPO-MULT] D.Papadimitriou, D.Ooms and J.Jones, æOptical
Multicast û A FrameworkÆ, Internet Draft, draft-poj-optical-
multicast-00.txt, February 2001.
9. [IPO-ONNI] D.Papadimitriou et al., æOptical NNI Framework and
Signaling RequirementsÆ, Internet Draft, draft-papadimitriou-
onni-frame-02.txt, February 2001.
10.[IPO-OPM] D.Papadimitriou et al., æOptical Signal Performance
Measurement,Æ Work in progress, draft-papadimitriou-optical-opm-
00.txt, February 2001.
11.[IPO-OUNI] B.Rajagopalan et al., æSignaling Requirements at
Papadimitriou et al. Expires August 2001 18
draft-papadimitriou-enhanced-lsps-02.txt February 2001
the Optical UNIÆ, Internet Draft, draft-bala-mpls-optical-uni-
signalling-01.txt, November 2000.
12.[IPO-SRLG] D.Papadimitriou et al., æInference of SRLGsÆ,
Internet Draft, draft-many-inference-srlg-00.txt, February 2001.
13.[IPO-TEIP] O.Duroyon et al., æLSP Service Model framework in
an Optical G-MPLS networkÆ, Internet Draft, draft-duroyon-te-ip-
optical-01.txt, November 2000.
14.[OIF2000.125.3] B.Rajagopalan et al., æUser Network Interface
(UNI) 1.0 ProposalÆ, OIF Contribution, December 2000.
15.[OIF2000.061.6] J.Yates et al., æUser to Network Interface (UNI)
Service Definition and Lightpath AttributesÆ, OIF Contribution
61, December 2000.
16.[OIF2000.188] R.Barry, æLightpath Attributes ProposalÆ, OIF
Contribution 188, August 2000.
17.[OIF2000.197] J.Heiles, æAlignment of the UNI with ITU-T
TerminologyÆ, OIF Contribution 197, September 2000.
18.[OIF2001.119] D.Pendarakis et al., æUNI Addressing:
Overview of Areas of Concern, Comments, and ProposalsÆ, OIF
Contribution 119, January 2001
19.[OIF2001.121] D.Pendarakis, æUNI addressing sub-group break-out
meeting recommendations
20.[VPN-ID] B.Fox and B.Gleeson, æVPN IdentifiersÆ, Internet RFC
2685.
8. Author's Addresses
Dimitri Papadimitriou
Alcatel IPO-NSG
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
Appendix 1: Terminology
Papadimitriou et al. Expires August 2001 19
draft-papadimitriou-enhanced-lsps-02.txt February 2001
The following terms are used in this document. These definitions
take into account the terminology already defined by the IETF for
some of the concepts defined here and some are adapted from the OIF
Forum terminology.
- Optical Network: a collection of optical sub-networks constituted
by optical network elements
- Optical Network Element (ONE): a network element belonging to the
optical network. An optical network device could be an Optical
Cross-Connect (OXC), Optical ADM (OADM), etc.
- Boundary ONE: an optical network element (ONE) belonging to the
optical network and including an UNI-N interface.
- Internal ONE: an optical network element internal to the optical
network (also referred as a termination incapable device) which does
not include a UNI-N interface.
- Client Network Element (CNE): a network element belonging to the
client network. A client network element could be a SONET/SDH ADM, a
SONET/SDH Cross-connect, an ATM Switch, an Ethernet switch, an IP
router, etc.
- Label Switched Path (LSP): point-to-point optical layer
connectivity with specified attributes (mandatory and optional)
established between two ONE termination-points in the optical
network. LSPs are considered as bi-directional (and in a first phase
as symmetric). A LSP could be a Fiber Switched path, Lambda Switched
path or TDM Switched path (Circuit).
- UNI Client (UNI-C): signalling and routing interface between a
Boundary CNE and a boundary ONE belonging to an optical network.
- UNI Network (UNI-N): signalling and routing interface between a
Boundary ONE and a boundary CNE belonging to a client network.
- UNI Services: the services defined at the UNI are the following:
- Neighbor discovery service
- Service discovery service
- LSP signalling services (create/delete/modify/status)
- NMI interface: the interface between the ONE controller and the
centralized management server.
Papadimitriou et al. Expires August 2001 20
draft-papadimitriou-enhanced-lsps-02.txt February 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.
Papadimitriou et al. Expires August 2001 21