CCAMP Working Group Eric Mannie (KPNQwest)
Internet Draft Dimitri Papadimitriou (Alcatel)
Expiration Date: November 2002
May 2002
GMPLS Signaling Extension to Control Conversion between
Contiguous and Virtual Concatenation for SONET and SDH.
draft-mannie-ccamp-gmpls-concatenation-conversion-01.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."
To view the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in an Internet-Drafts Shadow
Directory, see http://www.ietf.org/shadow.html.
Abstract
This document is a companion to the GMPLS extensions for SONET and
SDH control [GMPLS-SONET-SDH]. It defines a way to control and
negotiate the use of converters between contiguous and virtual
concatenation in SONET and SDH networks. A new flag in the
Requested Contiguous Concatenation (RCC) field is proposed for that
purpose.
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].
1. Introduction
When SONET/SDH LSPs are established and removed dynamically using
GMPLS signaling, some fragmentation of the SONET/SDH multiplex at
each interface can happen. For instance, it is possible to have some
free timeslots (holes) between larger set of allocated timeslots.
E.Mannie et al. Internet Draft û November 2002 1
draft-mannie-ccamp-gmpls-concatenation-conversion-01.txt May 2002
These holes cannot be used to route larger contiguously concatenated
signals.
This problem is expected to happen in a network where many non-
concatenated and contiguously concatenated signals of different
sizes are dynamically established and removed. This issue is similar
to the partitioning that could happen on a hard disk. After some
time, the fragmentation could be so high that it could be required
to re-arrange locally the usage of the timeslots between two nodes.
This process means that a local bridge and roll of circuits must be
done.
To avoid such a problem, the ideal solution is to use only virtual
concatenation allowing inherently re-using the holes. In that case,
the X individuals VC-4 signals constitute a VC-4-Xv. The individuals
VC-4's can be routed over different routes within the constraints
given by [G.707]. The concatenation information is contained in the
POH and is only required at the path termination equipment, i.e.
virtual concatenation does not require any functionality at
intermediate network elements.
However, most SONET/SDH equipmentÆs donÆt support virtual
concatenation at all. For instance, this is the case of most
SONET/SDH interfaces on IP routers. These interfaces being almost
exclusively contiguously concatenated interfaces (even not
channelized).
To solve this issue, conversion between contiguously concatenated
signals and virtually concatenated signals can be used (and vice
versa). [G.783] Section 12.5.2 specifies how to convert a
contiguously concatenated VC-4-Xc to a virtually concatenated VC-4-
Xv (and vice versa) through the use of the S4 interworking function.
A contiguously concatenated signal can be converted to a virtually
concatenated signal at the ingress of a cloud. The inverse
conversion can take place at the egress of the cloud. Ideally, such
converters should be available as close as possible to the nodes
that are only capable of contiguous concatenation. However, in a
heterogeneous network one cannot expect that such converters will be
available everywhere where they will be needed.
Normally, the conversion capability should be advertised in routing
protocols to allow finding a path with the right ingress and egress
converters. It will become complex if the ingress converter belongs
to one routing domain while the egress converter belongs to another
routing domain. On the other hand, one could consider that such
conversion capability can be available on a hop-by-hop basis at some
hops. In that case, the routing protocols and routing algorithms
donÆt need to take any new information into consideration. A path is
computed independently of the knowledge of converters and the
bandwidth optimization is done when available, on a hop-by-hop
basis.
E.Mannie et al. Internet Draft û November 2002 2
draft-mannie-ccamp-gmpls-concatenation-conversion-01.txt May 2002
In all cases the simple signaling extension defined in this document
allows to negotiate the use of conversion between neighbors. The
rules defined hereafter must be applied when using this extension.
2. Control of conversion between contiguous and virtual concatenation
This section defines the following optional extension flag for the
Requested Contiguous Concatenation (RCC) field of section 2.1 of
[GMPLS-SONET-SDH]:
Flag 3 (bit 3): Adaptable contiguous concatenation.
This flag allows an upstream node to signal to a downstream node
that it supports the adaptable contiguous concatenation type. This
type of concatenation does not correspond to any new type of
concatenation but is simply defined hereafter as a code-point to
allow to negotiate dynamically the use of contiguous to virtual
concatenation converters, and vice versa.
The mechanism defined in this document intends to maximize the use
of virtual concatenation. In addition, it allows negotiating the use
of virtual concatenation between the source and destination systems.
The use of virtual concatenation itself can in turn be controlled by
LCAS [G.7042] for instance. This extension is only applicable to VC-
4-Xc signals as defined in [G.783]. It is not in the scope of this
signaling specification to define how the conversion is done in the
transport plane.
The first LSR in the path supporting the conversion on its output
interface uses this extension to signal it (i.e. it sets the flag).
The flag is forwarded downstream with the adequate signaling message
until it reaches the destination. The first LSR may be the source
LSR itself, if it supports virtual concatenation and if it wants to
negotiate its use with the destination.
The destination answers positively with the adequate list of labels
if it supports virtual concatenation. The same is done in the
upstream direction at each hop, until it reaches the LSR providing
the conversion function (converter). Upstream of the converter, a
unique label is used until it reaches the source.
The signal is thus transported contiguously concatenated until it
reaches the first converter over the path and then it becomes
virtually concatenated until it reaches the destination.
Eventually, the positive answer reaches the source itself. In that
case, the signal is indeed virtually concatenated end-to-end. In
that case, this extension allows to request a contiguously
concatenated signal, and to negotiate the use of virtual
concatenation end-to-end. If supported, the virtual concatenation
will be used instead of the contiguous concatenation.
E.Mannie et al. Internet Draft û November 2002 3
draft-mannie-ccamp-gmpls-concatenation-conversion-01.txt May 2002
If virtual concatenation is not supported by the destination, a
single label is sent upstream by the destination. The same operation
is done upstream at each hop, until it reaches the first node, in
the upstream direction, able to convert from contiguous (single
label) to virtual (list of labels).
If such a node is found, a positive answer is sent upstream until it
reaches the node that has set up the flag. This node can be a
contiguous to virtual converter. In this case, the signal will be
transported contiguously concatenated from the source to the ingress
converter, then as virtually concatenated from the ingress converter
to the egress converter, and then finally as contiguously
concatenated from the egress converter to the destination.
Eventually, the negative answer (single label) reaches the source
itself. In that case, the signal is indeed contiguously concatenated
end-to-end.
Note that a converter having received the flag set from an upstream
node MUST NOT convert from virtual to contiguous in the upstream
direction (because there is upstream another converter closer to the
source).
Indeed, there are five possible cases and all are covered by the
mechanisms described here before:
1. Contiguous concatenation end-to-end.
2. Contiguous followed by virtual concatenation.
3. Virtual followed by contiguous concatenation.
4. Contiguous, then virtual then contiguous concatenation.
5. Virtual concatenation end-to-end.
This simple scheme triggers finding and using of the closest
converter to the source and the closest invert converter to the
destination. The routing algorithm does not need to compute a route
taking converters into consideration (but it may for additional
efficiency). Moreover, with this mechanism there is no need to
indicate explicitly in the signaling which node must convert in
which way, the most appropriate converter being selected
automatically.
Note that simply using the virtual concatenation indication allows
neither to change the concatenation type on the fly, nor negotiating
the concatenation type end-to-end. Adaptable contiguous
concatenation is a way to advertise that contiguous concatenation is
asked (most frequent case) but that virtual concatenation could be
done instead (less frequent case).
The adaptable contiguous concatenation flag MUST be used together
with standard contiguous concatenation flags. These flags allow
knowing the type of contiguous concatenation to apply in each
contiguously concatenated part of the network. Note that they donÆt
E.Mannie et al. Internet Draft û November 2002 4
draft-mannie-ccamp-gmpls-concatenation-conversion-01.txt May 2002
need to be the same in case 4, each contiguous segment can be
effectively in a different type.
This extension is compatible and can be combined with the virtual
concatenation of contiguously concatenated signals [GMPLS-SONET-SDH-
EXT] and the multiplier feature defined in [GMPLS-SONET-SDH]. If the
result of the concatenation negotiation is a virtual concatenation
in some part of the network, then the number, order and nature of
the corresponding SONET/SDH timeslots pointed by the labels
unambiguously indicates the result of the negotiation.
Note that the mechanism and extension defined in this document have
nothing to do with LCAS, and can be used with or without LCAS.
3. Acknowledgments
Valuable comments and input were received from Alexandre Geyssens,
Xavier Neerdaels and Philippe Noel.
4. Security Considerations
This draft introduces no new security considerations to [GMPLS-
SONET-SDH].
5. References
[G.707] "Network node interface for Synchronous Digital
Hierarchy (SDH)", Recommendation G.707, ITU-T, 10/2000.
[G.783] "Characteristics of Synchronous Digital Hierarchy (SDH)
equipment functional blocks", Recommendation G.783,
ITU-T, 10/2000.
[G.7042] "Link Capacity Adjustment Scheme (LCAS) for virtual
concatenated signals", Recommendation G.7042, ITU-T,
11/2001.
[GMPLS-SIG] L.Berger et al, "Generalized MPLS - Signaling
Functional Description", Internet Draft, draft-ietf-
mpls-generalized-signaling-08.txt, April 2002.
[GMPLS-LDP] L.Berger et al, "Generalized MPLS Signaling - CR-LDP
Extensions", Internet Draft, draft-ietf-mpls-
generalized-cr-ldp-06.txt, April 2002.
[GMPLS-RSVP] L.Berger et al, "Generalized MPLS Signaling - RSVP-TE
Extensions", Internet Draft, draft-ietf-mpls-
generalized-rsvp-te-07.txt, April 2002.
[GMPLS-ARCH] Mannie, E., Papadimitriou D. et al., "GMPLS
Architecture", Internet Draft, draft-ietf-ccamp-gmpls-
architecture-02.txt, March 2002.
E.Mannie et al. Internet Draft û November 2002 5
draft-mannie-ccamp-gmpls-concatenation-conversion-01.txt May 2002
[GMPLS-SONET-SDH] Mannie, E., Papadimitriou D. et al., "GMPLS
Extensions for SONET and SDH Control", Internet Draft,
draft-ietf-ccamp-gmpls-sonet-sdh-05.txt, May 2002.
[GMPLS-SONET-SDH-EXT] Mannie, E., Papadimitriou D. et al., "GMPLS
extensions to control non-standard SONET and SDH
features", Internet Draft, draft-ietf-ccamp-gmpls-
sonet-sdh-extensions-03.txt, April 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.
6. Authors' Addresses
Eric Mannie (KPNQwest)
Terhulpsesteenweg 6A
1560 Hoeilaart - Belgium
Phone: +32 2 658 5652
Email: eric.mannie@kpnqwest.com
Dimitri Papadimitriou (Alcatel)
Francis Wellesplein 1,
B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491
Email: dimitri.papadimitriou@alcatel.be
E.Mannie et al. Internet Draft û November 2002 6
draft-mannie-ccamp-gmpls-concatenation-conversion-01.txt May 2002
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 û November 2002 7