[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/