[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03 04 05
CCAMP Working Group Eric Mannie (Consult)
Internet Draft Dimitri Papadimitriou (Alcatel)
Expiration Date: August 2003 Lyndon Ong (Ciena)
February 2003
Generalized MPLS (GMPLS) LSP Bandwidth Modification (LBM)
for SONET/SDH Networks
draft-mannie-ccamp-gmpls-lbm-tdm-05.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."
Abstract
This document defines how Generalized MPLS (GMPLS) can be used to
dynamically modify the bandwidth of a Time Division Multiplexing
(TDM) Label Switched Path (LSP). It focuses first on Synchronous
Optical NETwork (SONET)/Synchronous Digital Hierarchy (SDH) and
intends to cover other switching technologies in a further release.
This document also defines how to use multiple differently routed
LSPs to build a single SONET/SDH virtually concatenated circuit
where each component LSP can be subsequently recovered (i.e.
protected or restored) individually.
E. Mannie et. al. - Internet-Draft û Expires August 2003 1
draft-mannie-ccamp-gmpls-tdm-lbm-05.txt February 2003
1. Introduction
Generalized MPLS (GMPLS) extensions to control Synchronous Optical
NETwork (SONET)/Synchronous Digital Hierarchy (SDH) networks are
defined in [GMPLS-SONET-SDH]. They specify the SONET/SDH traffic
parameters to be used for SONET/SDH LSP (i.e. unidirectional or bi-
directional. connection) requests.
Dynamically changing the bandwidth allocated for a SONET/SDH
connection is very useful for instance, when Ethernet traffic is
transported over SONET/SDH connections. According to the demand, the
size of a concatenated SONET/SDH connection can be modified
dynamically without having to reestablish a new connection, and
potentially to interrupt the service.
SONET/SDH, bandwidth modification can be achieved in very different
ways. If not using virtual concatenation it can be realized by
establishing another connection between the same source and
destination with different characteristics (e.g. signal type) and
then by switching the traffic to the newly established connection by
performing a switchover.
Using virtual concatenation allows the connection bandwidth to be
modified by adding and removing SPEs/VCs to a connection consisting
of multiple SPEs/VCs. Use of LCAS further allows this to be done
without disruption of service. This would ideally be achieved while
avoiding double counting (i.e. double reservation) the resources
while modifying the bandwidth by using for instance the concept of
make-before-break.
In practice, bandwidth modification is most efficiently done when
virtual concatenation is used since SPEs/VCs donÆt need to be
contiguous: they are transported individually and can even be routed
independently. This could also be achieved when using contiguous
concatenation but in practice this approach is much less likely to
happen since a bandwidth increase requires additional free SPEs/VCs
to be allocated at each interface traversed by the connection during
the switchover.
GMPLS signalling currently supports simultaneous setup of multiple
SPEs/VCs in a single setup request. This requires the SPEs/VCs
belonging to a single circuit to be routed through the same
Line/Multiplex section. This document extends the GMPLS procedures
to allow separate setup of multiple LSPs, possibly with disjoint
routing, to be coordinated at the endpoints. In that case, LSPs can
be set-up, maintained and deleted independently, while being part of
the same SONET/SDH circuit, as is desired for virtual concatenation.
LSPs can be co-routed through the same component TE link, through
different components of the same TE link or even routed completely
diversely, as far as T1X1/ITU-T requirements for differential delays
are respected (out of the scope of this document).
E. Mannie et. al. û Internet Draft û Expires August 2003 2
draft-mannie-ccamp-gmpls-tdm-lbm-05.txt February 2003
T1X1 and ITU-T Related Efforts:
------------------------------
Both have defined a protocol called Link Capacity Adjustment Scheme
(LCAS) for virtual concatenated (group) signals for SONET/SDH and
G.709 OTN (Optical Transport Networks), independently of any
distributed control plane. This signalling protocol transported in-
band in the Path Overhead (POH), for instance in SONET/SDH.
LCAS (see ITU-T [G.7042]) supports increasing or decreasing the
capacity of a virtual container that is transported using Virtual
Concatenation. In addition, LCAS will automatically decrease the
capacity if a member experience a failure in the network, and
increase the capacity when the network fault is repaired. LCAS,
however, does not define the mechanism whereby a VC member is
provisioned or released across the network.
For SDH, LCAS is defined for all VC types for which virtual
concatenation is defined, i.e. VC-4, VC-3, VC-2, VC-12 and VC-11.
Using LCAS, a VC can only be added at the end of a virtually
concatenated signal, but can be removed from any place. The
same
applies in SONET, where LCAS is defined for high order STS-1-Xv/STS-
3c-Xv and low-order VTn-Xv SPE (n = 1.5, 2, 3, 6).
Scope and coverage:
------------------
This document defines LSP Bandwidth Modification (LBM) procedures
and extensions for GMPLS using either virtual concatenation or
contiguous concatenation. It defines among other things the
combination of the signalling provided by GMPLS and LCAS at the
control and transport plane, respectively, to allow hitless
modification. Note the current version focuses on SONET/SDH and will
in a future release cover G.709 Optical Transport Networks (OTN).
Similarly to GMPLS, this document covers bandwidth modification of
unidirectional LSPs and bi-directional symmetric LSPs. Bi-
directional asymmetric LSPs setup is not supported by the current
GMPLS Signalling specification. In this context, the current
proposal allows for SONET/SDH bandwidth modification being requested
only by the initiator (source) of a circuit. A future version might
cover destination initiated bandwidth modification. It could also be
extended to cover modification of other connection attributes than
the bandwidth, like link protection/restoration characteristics.
This document extends GMPLS to allow multiple LSPs to support a
single circuit and subsequently covers bandwidth modification when
using multiple LSPs implementing a single circuit. This approach has
the drawback of requiring more signalling but seems to be more
appropriated when operating within the context of a global control
plane. It provides the advantage that each LSP can be routed
independently AND protected/restored independently. Note that GMPLS
E. Mannie et. al. û Internet Draft û Expires August 2003 3
draft-mannie-ccamp-gmpls-tdm-lbm-05.txt February 2003
LBM can be first used to modify the bandwidth of a single unique LSP
(circuit), without any LSP combination.
In brief, this document provides the required GMPLS signalling
extensions to cover the following bandwidth modification (i.e.
increase/decrease) scenarios:
- GMPLS LBM without Virtual Concatenation referred to as LBM using
a parallel LSP
- GMPLS LBM with Virtual Concatenation only
. with Single LSP Bandwidth Modification
. with Multiple LSP Combination (within a Circuit)
- GMPLS LBM with both Virtual Concatenation and LCAS using GMPLS for
LSP provisioning and LCAS for end-to-end (in-band) signalling
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 [RFC2119].
Moreover, the reader is assumed to be familiar with the terminology
in ANSI [T1.105], ITU-T [G.707] as well as [RFC-3471], [RFC-3473]
and [GMPLS-SONET-SDH]. The following abbreviations are used in this
document:
DCC: Data Communications Channel.
LOVC: Lower Order Virtual Container.
HOVC: Higher Order Virtual Container.
MS: Multiplex Section.
MSOH: Multiplex Section overhead.
POH: Path overhead.
PTE: Path Terminating Equipment.
RS: Regenerator Section.
RSOH: Regenerator section overhead.
SDH: Synchronous digital hierarchy.
SOH: Section overhead.
SONET: Synchronous Optical Network.
SPE: Synchronous Payload Envelope.
STM(-N): Synchronous Transport Module (-N) (SDH).
STS(-N): Synchronous Transport Signal-Level N (SONET).
VC-n: Virtual Container-n (SDH).
VTn: Virtual Tributary-n (SONET).
2. SONET/SDH Concatenation
2.1 SDH Virtual and Contiguous Concatenation
Section 11 of ITU-T [G.707] recommendation defines VC contiguous and
virtual concatenation. Contiguous concatenation maintains the
bandwidth contiguous through the whole network, while virtual
E. Mannie et. al. û Internet Draft û Expires August 2003 4
draft-mannie-ccamp-gmpls-tdm-lbm-05.txt February 2003
concatenation breaks the bandwidth into individuals VCs, transports
and routes these VCs individually from the source and then
recombines them at the path termination. Virtual concatenation
requires concatenation functionality only at the path termination
equipment, while contiguous concatenation requires concatenation
functionality at each network element:
- Contiguous concatenation is defined for VC-4s to provide a VC-4-Xc
(X=4, 16, 64, 256) and for VC-2s in a higher order VC-3 to provide
a VC-2-Xc (X=1,...,7).
- Virtual concatenation is defined for VC-4s, VC-3s, VC-2s, VC-12s
and VC-11s but all the VCs belonging to a virtually concatenated
circuit must be of the same type. The virtual concatenation of X
VC-4/3 (X=1,...,256) provides a VC-4/3-Xv. The number of low order
VCs that can be virtually concatenated together depends on the
higher order VC in which they are transported and is defined
according to table 11-9 in G.707.
Each VC has its own Path Overhead (POH):
- For low order VC: the VC-2/1 K4 POH byte in bit 2 is multi-framed
in 32 frames to form a 32 bits string and is used to indicate a
frame count and a sequence indicator. The frame count provides a
measure of the differential delay (see ITU-T G.707). Each VC-2/1
of a VC-2/1-Xv has a fixed unique sequence number in the range of
0 to X-1.
- For high order VC: the VC-4/3 H4 POH byte is used for the virtual
concatenation specific sequence and multi-frame indication. What
is important in the context of GMPLS LBM is that each VC-4/3 has a
fixed sequence number in the range of 0 to X-1.
These VC sequence numbers will be used by the GMPLS LBM procedures
to identify each frame unambiguously in the same virtually
concatenated circuit.
VCs can be routed and transported individually, even over different
multiplex sections, i.e. over different TE link components or over
different TE links. There are limitations due to the differential
delay between different routes (outside of the scope of this
document). GMPLS LBM provides the same level of flexibility, using
and combining multiple LSPs.
2.2 SONET Virtual and Contiguous Concatenation
ANSI [T1.105] recommendation defines VC contiguous and virtual
concatenation. Contiguous concatenation maintains the bandwidth
contiguous through the whole network, while virtual concatenation
breaks the bandwidth into individuals STS SPEs, transports and
routes these STS SPEs individually from the source and then
recombines them at the path termination. Virtual concatenation
requires concatenation functionality only at the path termination
E. Mannie et. al. û Internet Draft û Expires August 2003 5
draft-mannie-ccamp-gmpls-tdm-lbm-05.txt February 2003
equipment, while contiguous concatenation requires concatenation
functionality at each network element:
- Contiguous concatenation is defined for STS-1/STS-3c SPEs to
provide a STS-(3*X)c SPE (X=1, 4, 16, 64, 256)
- Virtual concatenation is defined for STS-1s, STS-3cs and VTn SPEs
(n = 1.5, 2, 3, 6) but all the STS/VT SPEs belonging to a
virtually concatenated circuit must be of the same type. The
virtual concatenation of X STS-1/STS-3c (X=1,...,256) provides
a STS-1-Xv/STS-3c-Xv SPE. The number of low order VTn SPEs (n =
1.5, 2, 3, 6) that can be virtually concatenated together depends
on the higher order STS-1/STS-3c SPE in which they are transported
as defined according to Table 8 of ANSI T1.105.
Each VT/STS SPE has its own Path Overhead (POH):
- For low order VT SPEs: the VTn Z7 POH byte in bit 2 is multi-
framed in 32 frames to form a 32 bits string and is used to
indicate a frame count and a sequence indicator. The frame count
provides a measure of the differential delay (see ANSI [T1.105]).
Each VTn SPE of a VTn-Xv SPE has a fixed unique sequence number in
the range of 0 to X-1.
- For high order STS SPEs: the STS-1/STS-3c H4 POH byte is used for
the virtual concatenation specific sequence and multi-frame
indication. It uses a two-stage multi-framing. As for SDH, the
important point in the context of GMPLS LBM is that each STS-
1/STS-3c SPE has a fixed sequence number in the range of 0 to X-1.
These sequence numbers will be used by the GMPLS LBM procedures to
identify each frame unambiguously in the same virtually concatenated
circuit. As for SDH, VTs/STS SPEs can be routed and transported
individually, even over different line sections, i.e. over different
TE link components or over different TE links.
3. Link Capacity Adjustment Scheme (LCAS)
Link Capacity Adjustment Scheme (LCAS) recommendation ITU-T [G.7042]
details the procedure to add (or remove) the payload carried by a
VC-4/VC-3 within a VC-n-Xv group (n = 3, 4) and to add (or remove)
the payload carried by a VC-11/VC-12/VC-2 within a VC-m-Xv group (m
= 11, 12, 2). Relying on virtual concatenation support, LCAS is
defined as an extended end-to-end signalling protocol transported
over the H4 overhead (for HOVC) and K4 overhead (for LOVC). The same
applies in SONET for high order STS-1-Xv/STS-3c-Xv and low-order
VTn-Xv SPE (n = 1.5, 2, 3, 6) signalling being transported over H4
and Z7 POH, respectively.
Running GMPLS at the control plane level and LCAS at the transport
plane level requires clear determination of the interactions between
these protocols. LCAS is an end-to-end (i.e. PTE-to-PTE) signalling
protocol enabling bandwidth modification at end systems relying on
group of virtually concatenated HOVC/STS SPE (or LOVC/VT SPE)
belonging to the same circuit and provisioned through
Element/Network Management Systems (EMS/NMS) or any distributed
control plane. However, LCAS doesnÆt provide setting up and
E. Mannie et. al. û Internet Draft û Expires August 2003 6
draft-mannie-ccamp-gmpls-tdm-lbm-05.txt February 2003
releasing connections between intermediate nodes. This means that
LCAS must be combined with an EMS/NMS system or any distributed
control plane in order for the global system to offer dynamic
connection(s) setup throughout the network. The proposed GMPLS
signalling extensions aim to deliver this capability including when
one of the two end systems supports only virtual concatenation.
4. GMPLS LBM with a Parallel Connection (no Virtual Concatenation)
This section describes how to modify the bandwidth of a connection
by establishing a new completely bandwidth disjoint connection and
moving the traffic to the newly established connection by doing a
switchover at the end-points. This procedure can be performed
manually or automatically. It also uses a simplified version of the
make-before-break concept.
A new disjoint connection is first established. It can be routed
differently from the original connection and may have completely
different traffic parameters. This new connection reserves its own
resources and before performing the switchover, some bandwidth may
be double reserved.
This is for instance the only way to change the bandwidth of an
SDH LSP from a non-concatenated VC type to a different non-
concatenated VC type. An example is when going from a VC-3 to a VC-4
for an IP/MPLS bandwidth upgrade. This situation is depicted in the
following figure:
Step 1: Make
----------- Working -----------
| |VC-3 |-----------------| VC-3| | Working active
| PTE |----- Make (GMPLS) -----| PTE |
| |VC-4 |<--------------->| VC-4| |
----------- -----------
Step 2: Share
----------- Working -----------
| |VC-3 |<--------------->| VC-3| | Working active
| PTE |----- Working -----| PTE |
| |VC-4 |<--------------->| VC-4| | Working standby
----------- -----------
Step 3: Break
----------- Break (GMPLS) -----------
| |VC-3 |<--------------->| VC-3| |
| PTE |----- Working -----| PTE |
| |VC-4 |-----------------| VC-4| | Working active
----------- -----------
E. Mannie et. al. û Internet Draft û Expires August 2003 7
draft-mannie-ccamp-gmpls-tdm-lbm-05.txt February 2003
With RSVP-TE, the procedures described in [RFC-3209] (Section 4.6.4)
can be used but with a FF (Fixed Filter) reservation style instead
of a SE (Share Explicit) style.
The major point is that the LSP destination must be able to
understand that 1) a new LSP is intended to replace an existing LSP
and 2) this newly setup LSP is not independent of the existing one.
This is achieved using the mechanism explained here above.
Moreover, the switchover from the working connection to the new
active one is strictly an end-point operation only. Also, one
expects that this operation can be performed within an upper bounded
period of time constraint whose definition is out of the scope of
this document. When this period of time satisfies the requestor
constraints, this mechanism can be considered as a non-disruptive
bandwidth service modification for that application.
5. GMPLS LBM with Virtual Concatenation
This section defines the procedures for SONET/SDH bandwidth
modification when virtual concatenation is used. It first defines
the procedures to add or remove VCs in a single LSP (Section 5.1),
and then the one enabling to combine several LSPs together (Section
5.2).
5.1 Single LSP Bandwidth Modification
This section is only applicable to the standard virtual
concatenation as defined by T1X1/ITU-T (see [T1.105] and [G.707],
respectively).
SONET/SDH LSP bandwidth modification can only be allowed when the
LSP is already set up and active, i.e. modification is not defined
or allowed during the LSP(s) establishment or release. Only
bandwidth modification requested by the ingress LSR of the LSP is
considered here. The Ingress LSR shall not modify an LSP before a
previous modification procedure is completed.
When a bandwidth modification is requested, an updated SONET/SDH
traffic parameter is sent downstream within a Path/Label
Request message. This request is explicitly identified as a
bandwidth modification request using a specific indication
mechanism.
With RSVP-TE, the procedures for bandwidth modification defined in
Section 4.6.4 of [RFC-3209] are used. The SENDER_TEMPLATE and the
Sonet/SDH SENDER_TSPEC objects carry respectively a modified LSP ID
and a modified SONET/SDH traffic parameter within the Path message
sent from the source LSR (i.e. head-end PTE) to the destination LSR
(i.e. tail-end PTE). This allows recognizing that a bandwidth
modification is requested.
Subsequently, the following alternative can be considered:
- If accepted, the same new traffic parameter is sent back to the
E. Mannie et. al. û Internet Draft û Expires August 2003 8
draft-mannie-ccamp-gmpls-tdm-lbm-05.txt February 2003
source indicating a bandwidth modification of a unidirectional or
a bi-directional LSP. This traffic parameter is transported in the
FLOWSPEC of the Resv message with RSVP-TE.
- If refused, the previously used SONET/SDH traffic parameter is
sent back to the source. It allows ensuring that the request for
bandwidth modification was well received and treated by the
destination without commitment of the requested modification.
Note also that the actual bandwidth allocation is committed when the
Resv message flows in the upstream direction.
A modified SONET/SDH traffic parameter SHOULD have a different NVC
field and MAY have a different MT field. The Multiplier field (MT)
SHOULD not be used since this field has a different semantic. All
other fields MUST be identical.
SPEs/VCs can only be added at the end of an LSP. For instance, when
adding Y VC-4s to a VC-4-Xv (where each of the VC-4 is numbered from
0 to X-1), one obtains a VC-4-(X+Y)v with the sequence numbered from
0 to X+Y-1.
The number Y of SPEs/VCs to add is given by the following equation:
ABS[(new NVC * new MT) - (old NVC * old MT)]. The first new SPE/VC
will have a sequence number equals to the sequence number of the
previously last VC + 1 (i.e. X).
Example:
Old Traffic Parameters: ST = VC-4 - NVC = 2 - MT = 1 (VC-4-2v)
Sequence: VC-4[0] = 0 and VC-4[1] = 1
New Traffic Parameters: ST = VC-4 - NVC = 4 - MT = 1 (ADD 2 VC-4)
Sequence: VC-4[2] = 2 and VC-4[3] = 3
GMPLS LBM explicitly allows the value of the traffic parameters to
change over time. Modified SONET/SDH traffic parameter indicates the
complete traffic parameters of the updated circuit and not a delta.
The delta computation is simply done by comparing the fields.
SPEs/VCs can be removed from an LSP but only at the end of that LSP
(i.e. starting at SPE/VC sequence number X-1). When a new traffic
parameter is sent requesting less SPEs/VCs, the difference is
removed from the end of the sequence. This is a limitation in
comparison with LCAS, which allows removal of any SPEs/VCs component
(independently of its position within the sequence).
Note: The sequence number of each SPE/VC is transported in the
corresponding POH according to the SONET/SDH specifications. So, it
is not necessary to transport these sequence numbers in GMPLS
signaling since they are implicitly deduced at each end according to
the order of operations. When adding or removing SPEs/VCs, the
sequence numbers of the other (i.e. previous) SPEs/VCs of the same
LSP are not modified and stay identical.
E. Mannie et. al. û Internet Draft û Expires August 2003 9
draft-mannie-ccamp-gmpls-tdm-lbm-05.txt February 2003
5.2 Multiple LSPs Combination
The reasons to combine multiple LSPs to provide one larger SONET/SDH
circuit were already explained before. Such a combination requires
that all LSPs belonging to the same circuit be clearly identified as
belonging to the same group and as being in a given order. Defining
an additional Circuit ID and an LSP Sequence Number in GMPLS
signalling [RFC-3471] enables to achieve this. Obviously, each LSP
of the combination may have a different number of SPEs/VCs.
The following rules are defined together with the introduction of
the Circuit ID and the LSP Sequence Number:
- All LSPs belonging to the same circuit MUST have the same Circuit
ID
- All LSPs MUST have a unique LSP sequence number in that Circuit ID
The LSP sequence number MUST be the sequence number of the first
SPE/VC of the virtually concatenated circuit. This sequence number
is a redundant information with respect to the SONET/SDH SPE/VC
sequence number transported in the POH. Therefore, this allows for
an additional level of consistency checking between the control
plane and the transport plane.
From the GMPLS signalling point of view (see also Section 5.4),
these LSPs are seen as totally independent and being uniquely
identified in RSVP-TE by the SESSION object together with the
SENDER_TEMPLATE object (in Path message) or FILTER_SPEC object (in
Resv message). They can be co-routed or not. They can be routed
explicitly diversely or not. They can fail separately and be
individually protected/restored or not.
Therefore, in this context, the GMPLS LBM "application" can be
considered as providing at the top of the control plane, a method
for managing individual LSPs made of virtually concatenated VCs to
build a larger SONET/SDH virtually concatenated circuit. This
"application" SHOULD only be supported at each end of an SONET/SDH
circuit without impacting intermediate nodes.
All SPEs/VCs corresponding to a new LSP can only be added at the end
of the virtually concatenated signal sequence. In that case, the
SPE/VC sequence number of the first SPE/VC is the sequence number of
the last SPE/VC of the last LSP + 1.
When an LSP is removed, for whatever reason, all its SPEs/VCs are
removed. This implies that sequence numbers of other SPEs/VCs
belonging to the LSPs logically following the removed LSP MUST be
renumbered. The same is done for the LSP sequence numbers. However,
this is not an issue since all the LSPs are initiated by the same
entity.
Note that when combined to the single LSP control-driven (meaning
initiated by the source node and not an external event) bandwidth
modification procedure defined here before, SPEs/VCs of an LSP can
be removed starting from its last members (stack method). It results
E. Mannie et. al. û Internet Draft û Expires August 2003 10
draft-mannie-ccamp-gmpls-tdm-lbm-05.txt February 2003
in a multi-LSP configuration that SPEs/VCs can also be removed
independently of a complete LSP removal but with the given
restriction.
All LSPs belonging to the same virtually concatenated signal MUST
have the same SONET/SDH traffic parameters, except for the NVC and
MT fields. Note however that the use of the multiplier (MT) in that
context is not at all recommended.
5.3 SPE/VC recognition and significance
When a modification occurs in a virtually concatenated signal, the
receiving end needs to know which SPE/VC is part of the circuit and
when the content of each SPE/VC is valid.
A SPE/VC is considered as being part of circuit when it is signaled,
i.e. when the corresponding Resv message is sent back to the source.
The SPE/VC content is considered as significant when it is received
with a specific indication in the POH (it can also be located for
HOVC/STS SPE in the H4 POH byte as defined by LCAS) and a valid
sequence number according to the receiving end status.
The sequence number transported in the POH has a global significance
per circuit not per LSP. Since multi-frames are used, the sequence
number is considered usable only when the last bit of the multi-
framed field has been received.
Note: to ensure that in the upstream direction the destination end
doesnÆt send traffic before the source completed the bandwidth
modification; the destination end MAY simply wait for a ResvConf to
be received.
5.4 GMPLS Signalling Extensions
This memo requires the encoding and transport of a Circuit ID and an
LSP Sequence Number for all LSPs being established according to the
procedures of Section 5.2. Having a Circuit ID even for a single LSP
circuit further allows adding LSPs to this circuit.
A Circuit ID object is defined to identify all LSPs belonging to the
same SONET/SDH circuit inside of which the Sequence Number
identifies each (component) LSP.
This can be achieved by defining in addition to the one specified in
RSVP-TE (see [RFC-3209]) an extended SENDER_TEMPLATE C-Type (with
Class-num = 11 and C-Type = TBA), and extended FILTER_SPEC C-Type
(with Class-num = 10 and C-Type = TBA). Both objects have the
following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E. Mannie et. al. û Internet Draft û Expires August 2003 11
draft-mannie-ccamp-gmpls-tdm-lbm-05.txt February 2003
| MUST be zero | LSP Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Circuit ID field (32 bits)
This is a unique Circuit ID number, generated by the source. It
is unique in the context of the source and does not change during
the lifetime of the circuit.
In the current version, when used this field MUST be non-zero.
- LSP Sequence Number field (16 bits)
This is a unique sequence number in the context of the Circuit
ID. It allows ordering the LSP in the SONET/SDH virtually
concatenated signal. Numbering MUST start at 0. This field is
relevant only when fixed timeslot allocation is provided at
virtual concatenation end-points.
Note: following the above definitions a single circuit LSP will have
a Circuit ID =/= 0 and a LSP Sequence Number = 0. One expects that
the Circuit ID numbering will be ordered.
Processing rules:
----------------
The proposed SENDER_TEMPLATE/FILTER_SPEC object extensions are only
relevant at the sender and receiver nodes. The corresponding objects
MUST be forwarded unmodified by any intermediate node that receives
them in both downstream (Path message) and upstream (Resv message)
directions. Maintenance of this object in the local PSB is optional,
thus the current path records can be left unmodified (compose by the
EXPLICIT ROUTE object, SESSION object and SENDER_TEMPLATE object)
from its current implementation.
If a receiver node does not support the SENDER_TEMPLATE extension
described here above, a PathErr message MUST be sent back towards
the sender node with Error Code 14 (Unknown object C-Type). If for
the same Circuit ID a duplicated LSP Sequence Number is received,
the receiver MUST send a PathErr message towards the sender with
Error Code 14, and log locally the following error ôInvalid/Illegal
Sequence Valueö.
The sender node having inserted the SENDER_TEMPLATE by default
SHOULD support the corresponding FILTER_SPEC processing, otherwise a
ResvErr message MUST be sent back towards the receiver node with
Error Code 14 (Unknown object C-Type).
6. GMPLS LBM with both Virtual Concatenation and LCAS
This section describes a sequential combination of GMPLS and LCAS.
The proposed mechanism runs GMPLS between virtual concatenation
capable end-points for provisioning of a given HOVC/STS (LOVC/VT)
Group (also referred to as capacity initiation, increase or decrease
E. Mannie et. al. û Internet Draft û Expires August 2003 12
draft-mannie-ccamp-gmpls-tdm-lbm-05.txt February 2003
in ITU-T [G.7042]) and discovery of the destination support for
LCAS. After this, the addition or removal of the payload carried in
the HOVC/STS SPE (or LOVC/VT SPE) Group member(s) belonging to the
provisioned HOVC/STS (LOVC/VT) Group is performed using LCAS end-to-
end signalling.
Note: that in the present application, GMPLS LBM does not replace or
overlap with the end-to-end LCAS signalling and does not preclude
the usage of other methods (out of the scope of the present
document) for capacity initiation, increase or decrease.
The detailed mechanism can be described as follows:
1. Bandwidth initiation, increase or decrease:
1a. Path message initiated from the Source towards the
Destination that indicates the (new, in case of increase or
decrease) Traffic Parameter values i.e. NVC and MT together
with the capability of the Source to support LCAS; this
operation is performed by using a dedicated Modifiable flag
(M flag) in the ADMIN_STATUS object (see [RFC-3473]). This
flag MUST follow exactly the same rules as the ones defined
for any other ADMIN STATUS flag (see [RFC-3473]).
2a. Resv Message sent back by the destination towards the source
(as described in Section 5.1) in addition to the indication
by the receiver of LCAS support using the M flag reflection.
When LCAS is supported at both ends (2) described here below
applies, on the contrary, when LCAS is not supported by at least
one end, (3) applies.
2. LCAS End-to-end signalling (add/remove group member)
- If LCAS is supported by both ends and a bandwidth increase/
decrease is triggered at the source for a unidirectional LSP:
3a. LCAS end-to-end signalling protocol used to exchange the H4
CTRL messages
4a. Trigger the H4 NORM value and use the allocated bandwidth
- If LCAS is supported by both ends and a bandwidth increase/
decrease is triggered at the source for a bi-directional LSP:
3b. LCAS end-to-end signalling protocol used to exchange the H4
CTRL messages
4b. Trigger the H4 NORM value and use the allocated bandwidth
3. GMPLS LBM Signalling
- If LCAS is NOT supported by at least one end, then LCAS
messages are ignored by the non-supporting end which therefore
only provides virtual concatenation capability. In this case
the addition or removal of the HOVC/SPE (or LOVC/VT SPE)
components belonging to the virtually concatenated circuit is
driven by GMPLS LBM signalling as described in Section 5.1.
E. Mannie et. al. û Internet Draft û Expires August 2003 13
draft-mannie-ccamp-gmpls-tdm-lbm-05.txt February 2003
There are no additional GMPLS signalling extensions (compared to the
one proposed for virtual concatenation û see Section 5.4) required
when LBM is used in combination with LCAS, except the additional M
flag in the ADMIN STATUS object. Processing of this flag MUST follow
the rules defined in [RFC-3473] for any other flag.
7. Security Considerations
This draft introduces no new security considerations to [GMPLS-
SONET-SDH].
8. Acknowledgments
The authors would like to thank J. Jones, G. Grammel, A. Bellato,
S. Ansorge, S.De Cnodder and H. van Helvoort for their useful
feedback.
Valuable comments and input were also received from A. Geyssens,
M. Moelants, X. Neerdaels and P. Noel and F. Yin.
9. References
[GMPLS-ARCH] Mannie, E. (Editor), "GMPLS Architecture", Internet
Draft, draft-ccamp-ietf-gmpls-architecture-03.txt,
August 2002.
[GMPLS-SONET-SDH] Mannie, E. (Editor), "GMPLS Extensions for SONET
and SDH Control", Internet Draft, draft-ietf-ccamp-
gmpls-sonet-sdh-07.txt, October 2002.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services," RFC 2210, September 1997.
[RFC3209] Awduche D., et al., "RSVP-TE: Extensions to RSVP for
LSP Tunnels," RFC 3209, December 2001.
[RFC3471] Berger, L. (Editor) et al., "Generalized MPLS û
Signaling Functional Description", RFC 3471, January
2003.
[RFC3473] Berger, L. (Editor) et al., "Generalized MPLS
Signaling - RSVP-TE Extensions", RFC 3473, January
2003.
[G.707] ITU-T, ôNetwork Node Interface for the Synchronous
Digital Hierarchyö, G.707 Recommendation, October
2000.
[G.7042] ITU-T, ôLink Capacity Adjustment Scheme (LCAS) for
Virtual Concatenated Signalsö, G.7042 Recommendation,
E. Mannie et. al. û Internet Draft û Expires August 2003 14
draft-mannie-ccamp-gmpls-tdm-lbm-05.txt February 2003
October 2001.
[T1.105] ANSI, "Synchronous Optical Network (SONET): Basic
Description Including Multiplex Structure, Rates, and
Formats", T1.105 Recommendation, January 2001.
10. Authors' Addresses
Eric Mannie (Consult)
Email: eric_mannie@hotmail.com
Dimitri Papadimitriou (Alcatel)
Francis Wellesplein 1,
B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491
Email: dimitri.papadimitriou@alcatel.be
Lyndon Ong (Ciena)
5965 Silver Creek Valley Road
San Jose, CA 95138, USA
Email: lyong@ciena.com
E. Mannie et. al. û Internet Draft û Expires August 2003 15
draft-mannie-ccamp-gmpls-tdm-lbm-05.txt February 2003
11. 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."
E. Mannie et. al. û Internet Draft û Expires August 2003 16
Html markup produced by rfcmarkup 1.129b, available from
https://tools.ietf.org/tools/rfcmarkup/