CCAMP Working Group Dimitri Papadimitriou
Internet Draft Jim Jones
Category: Standard Track Alcatel
Expiration Date: August 2003 February 2003
(FA-)LSP Initiation and Bundling
using Link Management Protocol (LMP)
draft-papadimitriou-ccamp-lmp-initiation-02.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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.
For potential updates to the above required-text see:
http://www.ietf.org/ietf/1id-guidelines.txt
1. Abstract
This memo is a companion document to Link Management Protocol (LMP),
for which it details the Forwarding Adjacency LSP (FA-LSP)
Initiation and Bundling process. [LMP] protocol is being developed
as part of the Generalized MPLS (GMPLS) protocol suite to control
and manage Traffic Engineering (TE) Links. The current document
extends the LMP capabilities to FA-LSPs enabling among other to
dynamically configure TE Links (in particular the LSP it can serve)
between non-adjacent LSRs.
2. 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 [2].
D.Papadimitriou Internet Draft - Expires August'03 1
draft-papadimitriou-ccamp-lmp-initiation-02.txt February 2003
3. Introduction
The Link Management Protocol [LMP] protocol has demonstrate its
value in automating Generalized MPLS (GMPLS) operations. This
protocol is being developed as part of the GMPLS protocol suite to
control and manage Traffic Engineering (TE) Links (aka link
bundles). LMP currently consists of four main functions, of which,
the first two are mandatory and the last two are optional (depending
on the capabilities provided by the transport plane):
1. Control channel management
2. Link property correlation
3. Link verification
4. Fault management
Control channel management is used to establish and maintain control
channel connectivity between adjacent nodes. As such, this function
enables the maintenance of the control plane adjacencies. This is
performed using a Config message exchange followed by a lightweight
keep-alive message exchange (a.k.a. Hello protocol). Link property
correlation is used to aggregate multiple data links into a single
TE Link and to synchronize their link properties. Link verification
is used to verify the physical connectivity of the data bearing
links and to exchange their identifiers (a.k.a discovery). Fault
management functions include alarm suppression and fault
localization in both opaque and transparent networks.
Note: control channel bootstrapping is described in [LMP-BOOT].
4. FA-LSP Initiation and Bundling - Overview
In this document, we extend the LMP capabilities to enable
Forwarding Adjacency LSP (FA-LSP) initiation and bundling. The
usefulness of the proposed mechanism is illustrated by the following
multiple LSP Regions topology:
LSR(X) <--------------------- LMP ---------------------> LSR(Y) N+1
| |
| |
| |
LSR(X) <--LMP--> LSR(1) <--.. LMP ..--> LSR(M) <--LMP--> LSR(Y) N
Typically, LSR(1) to LSR(N) belongs to one LSP region (for instance,
LSC) and the LSPs established through these nodes crosses the LSP
region boundary at LSR(X) and LSR(Y) that belongs for instance to
the TDM region (see [MPLS-HIER]). When dealing with non-PSC layers
the LSP and TE Links are defined as the control plane mapping of the
transport plane paths and sections. Therefore, the LSP established
at region N appears as a TE link at region N+1 and are referred to
as a Forwarding Adjacency LSP (FA-LSP).
D.Papadimitriou - Internet Draft - Expires August'03 2
draft-papadimitriou-ccamp-lmp-initiation-02.txt February 2003
Note: such hierarchy is referred to as "hierarchical TE Link" when
the instance of the control plane having raised the LSP at layer N
is distinct from the one using this link to setup an LSP at layer
N+1. Corresponding considerations are outside out of the scope of
this document.
In this context, the main issues are on one hand related to the TE
Link identification and assignment performed at region N while only
its component links may be the object of an FA-LSP setup. Note also
that once these FA-LSPs are setup they appear at region N+1 with the
interface switching capability having raised these LSPs. For
instance, the triggering of an FA with TDM interface switching
capability is possible if both LSR(X) and LSR(Y) through the TE
Links they define with their neighboring nodes (i.e. LSR(1) and
LSR(M)) give access to an LSC switching capability region. Another
example is the initiation of FA's with LSC interface switching
capability through a Waveband LSP region as described in [GMPLS-WB].
Moreover, when a FA-LSP is dynamically triggered the TE attributes
of its corresponding FA are inherited from the LSP, which induced
its creation.
On the other hand, the correlation of FAs having similar Traffic
Engineering (TE) attributes can induce the creation of an FA bundle
(here, in this example between LSR(X) and LSR(Y)) whose number of
components is at most as large as the number of components of the TE
Links defined between LSR(X) and LSR(1) and between LSR(M) and
LSR(Y), respectively.
Note: there is a similarity between this and the context where [LMP-
WDM] protocol is defined: LSR(X) and LSR(Y) corresponds to OXC and
LSR(1) to LSR(M) to Optical Line System (OLS); the only exception is
that in the latter case, one of the LMP neighbor is a non GMPLS-
capable node.
5. (FA-)LSP Initiation
(FA-)LSP initiation runs over an LMP adjacency and is invoked each
time an LSP is setup between a pair of ingress-egress LSRs belonging
to the same LSP region. To initiate an LMP adjacency between these
nodes at least one bi-directional control channel MUST be activated.
Once an LMP adjacency has been brought up, LMP session information
can start between the ingress-egress LSR pair.
The exact implementation of this control channel is not specified in
this document. It could be, for example, a dedicated wavelength, an
Ethernet link, or an IP tunnel defined between ingress LSR(1) and
egress LSR(M), or even the overhead bytes of a data-bearing link.
Rather, a node-wide unique 32-bit non-zero integer control channel
identifier (CCId) is assigned at each end of the control channel.
This identifier comes from the same space as the unnumbered
interface Id.
D.Papadimitriou - Internet Draft - Expires August'03 3
draft-papadimitriou-ccamp-lmp-initiation-02.txt February 2003
The control channel defined between LSR(X) and LSR(Y) is either
permanently maintained (in this case the control channel is
explicitly configured) or established on-demand (in this case the
control channel is dynamically configured and selected). As
described in [LMP] (see Section 3), once a control channel is
activated between two nodes, the LMP Hello protocol (see [LMP]
Section 3.2) can be used to maintain control channel connectivity
between the nodes and to detect control channel failures. This Hello
exchange is intended to be a lightweight keep-alive mechanism that
will react to control channel failures rapidly. Note that
subsequently this control channel can be used for signalling message
exchange between LSR(X) and LSR(Y) while routing channels are vy
definition kept separated.
Therefore, FA-LSP initiation can be invoked only after control
channel setup completion between LSR(X) and LSR(Y) but also between
LSR(X) and LSR(1) at the head-end (ingress) and between LSR(N) and
LSR(Y) at the tail-end (egress). Note that the LSR(X) to LSR(Y) LMP
session can use the same transport medium as the ingress and egress
LMP sessions (these sessions may be used as entry point). This
procedure consists of a sequence of LMP message exchanges between
the ingress LSR(X) and egress LSR(Y) prior to the LSP establishment
between these end-points. Consequently, when used, the FA-LSP
initiation MUST be performed before the corresponding LSP is
established.
Once the FA-LSP has been initiated, it can be established and the
created entity (i.e. the FA) used for path computation purposes by
the upper LSP region as any other TE Link belonging to this region
(see [MPLS-HIER]).
6. FA-LSP Verification
After the FA-LSP establishment (see [RFC-3471] and [MPLS-HIER]),
verification of the newly created Lambda LSP can be performed at any
time the FA-LSP is not in the property correlation process (see
Section 6). This verification can be performed either using [LMP-
SONET-SDH] in case of TDM FA-LSP and [LMP] in case of non TDM FA-
LSP.
Note that verification can only be performed on already initiated
and established FA-LSPs.
7. FA-LSP Bundling
The messages defined in [LMP] for Link Property Correlation are used
for FA-LSP bundling purposes: LinkSummary (MsgType = 14),
LinkSummaryAck (MsgType = 15) and LinkSummaryNack (MsgType = 16).
The contents of these messages are built using existing (see [LMP]
Section 13) and additional LMP sub-objects, which can be either
negotiable or non-negotiable. Here, negotiable objects are used to
let both sides agree on the acceptance of certain parameters for the
D.Papadimitriou - Internet Draft - Expires August'03 4
draft-papadimitriou-ccamp-lmp-initiation-02.txt February 2003
requested LSP. Non-negotiable objects are used for announcement of
specific values that do not need, or do not allow, negotiation.
These messages are exchanged between the ingress and the egress LSR
(through the control channel) and used as follows. When the ingress
LSR has established an FA-LSP and wants to add/remove this FA-LSP
from an existing bundle of FA-LSPs, it sends a LinkSummary message
to the egress LSR indicating its local TE Link and data bearing link
information (including status and availability) while requesting the
corresponding information from the remote side. Since the ingress
LSR can be aware of the remote node TE Link and data bearing link
information, this request MAY include the remote side information.
The LinkSummary message can also be used to aggregate simultaneously
multiple established FA-LSP into a bundle of FA-LSPs. In addition to
add/remove a FA-LSP from an existing bundle of FA-LSPs, it can also
change the FA-LSPs correlation parameters.
Remember here that each TE Link has an identifier (TE Link_Id) that
is assigned at each end of the TE Link (local and remote Link Id).
These identifiers MUST be the same type (i.e. IPv4, IPv6,
unnumbered) at both ends. Similarly, each component interface is
assigned an identifier (Interface_Id) at each end. These identifiers
MUST be of the same type at both ends. Interface Id values MUST be
taken from the space used for local LMP sessions.
If the LinkSummary message is received from a remote node and the
Interface Id mappings match those that are stored locally, then the
two nodes have agreement on Interface Id and TE Link Id if these are
known by the ingress.
The LinkSummaryAck message is used to signal an agreement (including
availability and status) on ALL the parameters both negotiable and
non-negotiable received in the LinkSummaryAck message. This
agreement includes the Interface Id mapping and data-bearing link
correlation properties in addition to the TE Link Id mapping if
known by the ingress LSR. Moreover, when sending such a message, the
receiver's data links support the capabilities listed in the
LinkSummary message.
Otherwise, a LinkSummaryNack message MUST be sent as response to
indicated which Interface Id mappings are not correct and/or which
data bearing link properties are not accepted. If a LinkSummaryNack
message indicates that the Interface Id mappings are not correct it
means that an error from a previous information has occurred (such
issues are outside of the scope of this document). If a
LinkSummaryNack message includes negotiable parameters, then
acceptable values for those parameters MUST be included. If a
LinkSummaryNack message is received and includes negotiable
parameters, then the initiator of the LinkSummary message MUST send
a new LinkSummary message that SHOULD include new values for the
negotiable parameters. These values SHOULD take into account the
acceptable values received in the LinkSummaryNack message.
D.Papadimitriou - Internet Draft - Expires August'03 5
draft-papadimitriou-ccamp-lmp-initiation-02.txt February 2003
Last, the following data structures are maintained at the ingress
(LSP initiator) and the egress (LSP receptor or destinator) LSR:
- Retransmission Timer, r: This configurable timer is set by a node
sending a LinkSummary message. The timer is reset if an
LinkSummaryAck or LinkSummaryNack message is received for this
message. The expiry of this timer results in the retransmission of
the LinkSummary message. The default value of this timer is 1
second.
- Number of Retransmissions, n: This configurable parameter
indicates the maximum number of allowed retransmissions of
LinkSummary messages. The default value of this number is 3. A
node considers the LSP Initiation procedure to have failed if a
response is not received from the peer after n retransmission
attempts.
Note: if the ingress LSR i.e. the LSP initiator, receives more than
one LinkSummaryAck/Nack after having issued a second (or subsequent)
LinkSummary message after retransmission timer expiration, only the
last LinkSummaryAck/Nack message is considered by the initiator.
8. Security Considerations
LMP provides authentication on a per IP Control Channel basis. The
packet authentication procedure is very similar to the one used in
OSPF, including multiple key support, key management, etc. The
details specific to LMP are defined in [LMP] Section 13.3.
9. References
[RFC-2026] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-3471] Berger, L. et al, "Generalized MPLS - Signaling
functional description," IETF RFC 3471, February 2003.
[G.707] ITU-T G.707, "Network node interface for the
synchronous digital hierarchy (SDH)," March 1996.
[GR.253] GR-253-CORE, "Synchronous Optical Network (SONET)
Transport Systems: Common Generic Criteria," Telcordia
Technologies, Issue 3, September 2000.
[GMPLS-WB] Douville, R., et al. "Extensions to Generalized MPLS in
support of Waveband Switching", Internet Draft, Work in
Progress, draft-douville-ccamp-gmpls-waveband-
extensions-03.txt, February 2003.
D.Papadimitriou - Internet Draft - Expires August'03 6
draft-papadimitriou-ccamp-lmp-initiation-02.txt February 2003
[GMPLS-RTG] Kompella, K., et al, "Routing Extensions in Support of
Generalized MPLS," Internet Draft, Work in Progress,
draft-ietf-ccamp-gmpls-routing-05.txt, May 2002.
[LMP] Lang, J.P. (Editor), et al, "Link Management Protocol,"
Internet Draft (work in progress), draft-ietf-ccamp-
lmp-07.txt, October 2002.
[LMP-BOOT] Lang, J.P., Drake, J. and Papadimitriou, D., "Control
Channel Bootstrap for LMP," Internet Draft (work in
progres), draft-lang-ccamp-lmp-bootstrap-03.txt,
February 2003.
[LMP-WDM] Fredette, A., Lang, J. P., (Editors), "Link Management
Protocol (LMP) for DWDM Optical Line Systems," Internet
Draft (work in progress), draft-ietf-ccamp-lmp-wdm-
01.txt, November 2002.
[MPLS-BUND] Kompella, K. et al., "Link Bundling in MPLS Traffic
Engineering," Internet Draft (work in progress), draft-
ietf-mpls-bundle-04.txt, August 2002.
[MPLS-HIER] Kompella, K. and Rekhter, Y., "LSP Hierarchy with
Generalized MPLS TE," Internet Draft (work in progress,
draft-ietf-mpls-lsp-hierarchy-08.txt, September 2002.
10. Acknowledgments
The authors would like to thank Bernard Sales, Emmanuel Desmet, Gert
Grammel, Mike Sexton and John Drake for their constructive comments
and inputs.
11. Author's Addresses
Dimitri Papadimitriou (Alcatel)
Francis Wellesplein, 1
B-2018 Antwerpen, Belgium
Phone: +32 3 240 8491
Email: dimitri.papadimitriou@alcatel.be
Jim Jones (Alcatel)
3400 W. Plano Parkway,
Plano, TX 75075, USA
Phone: +1 972 519-2744
Email: jim.d.jones1@usa.alcatel.com
D.Papadimitriou - Internet Draft - Expires August'03 7
draft-papadimitriou-ccamp-lmp-initiation-02.txt February 2003
12. 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."
D.Papadimitriou - Internet Draft - Expires August'03 8