Network Working Group A. Kern
Internet-Draft A. Takacs
Intended status: Informational Ericsson
Expires: September 2, 2010 March 1, 2010
Use cases and alternatives for configuring intermediate nodes using
RSVP-TE
draft-kern-ccamp-intermediate-node-config-00
Abstract
Lately, a few use-cases have been identified where, besides path
setup, specific configuration of intermediate nodes is required for
the establishment of an LSP with its associated functions. Today,
RSVP-TE is not supporting the selective configuration of intermediate
nodes; hence extensions are required to equip RSVP-TE with such a
capability. In this document we summarize the use-cases and their
requirements and sketch alternative solutions to configure
intermediate nodes. Since one of the main issues with intermediate
node configuration is the introduction of potential scaling problems,
we included scalability in our analysis. This document does not
specify any extensions; its sole purpose is to foster discussion on
the subject.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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.
This Internet-Draft will expire on September 2, 2010.
Kern & Takacs Expires September 2, 2010 [Page 1]
Internet-Draft Configuring middle nodes with RSVP-TE March 2010
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Amount of configuration data . . . . . . . . . . . . . . . . . 4
2.1. WSON Regeneration . . . . . . . . . . . . . . . . . . . . 4
2.2. OAM Configuration of Non-Intrusive Monitoring Entities . . 4
2.3. OAM Configuration of Tandem Connection Monitoring
Entities . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. RSVP-TE signaling alternatives . . . . . . . . . . . . . . . . 6
3.1. Using the LSP_ATTRIBUTES Object . . . . . . . . . . . . . 6
3.2. Using the HOP_ATTRIBUTES Sub-Object in ERO . . . . . . . . 6
3.3. Combination of LSP_ATTRIBUTES and ERO . . . . . . . . . . 6
3.4. Using multiple messages . . . . . . . . . . . . . . . . . 7
3.4.1. Multiple messages with semantic fragmentation . . . . 7
3.4.2. Using other signaling messages/procedures . . . . . . 7
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Kern & Takacs Expires September 2, 2010 [Page 2]
Internet-Draft Configuring middle nodes with RSVP-TE March 2010
1. Introduction
Lately, a few use-cases have been identified where, besides path
setup, specific configuration of intermediate nodes is required for
the establishment of an LSP with its associated functions.
GMPLS is being extended to support Wavelength Switched Optical
Networks (WSON) [WSON-FWK]. In the context of WSON, in
[WSON-SIGNAL], it has been identified that in addition to setup the
path and configure endpoints of an LSP to input and output a signal
with specific attributes, it may be need to signal particular
intermediate NEs to perform specific processing, such as 3R
regeneration, on the signal. Three types of processing are named
which may need configuration at particular intermediate nodes of an
LSP: 1) regeneration, 2) fault and performance monitoring and 3)
signal attribute conversion.
[GMPLS-OAM-FWK] describes GMPLS RSVP-TE signaling extension to
configure Operations and Management (OAM) functions associated to a
connection. Two OAM entities are differentiated: Maintenance
Endpoints (MEPs) that are deployed at connection endpoints and
Maintenance Intermediate Points (MIPs) that can be deployed at
intermediate nodes. The procedures described in [GMPLS-OAM-FWK]
support the detailed configuration of MEPs while for MIPs only the
instantiation at every or none of the intermediate nodes is
supported.
However, transport technologies, such as SDH and OTN provide a rich
set of monitoring functions which would require besides detailed MEP
configuration, the selective configuration of MIPs as well. For
instance, a part of an end-to-end connection can be monitored with
the help of tandem connection monitoring (TCM) running between two
intermediate nodes, or the end-to-end data flow can be monitored in a
non-intrusive fashion at particular intermediate NEs.
Kern & Takacs Expires September 2, 2010 [Page 3]
Internet-Draft Configuring middle nodes with RSVP-TE March 2010
2. Amount of configuration data
2.1. WSON Regeneration
In [WSON-SIGNAL] only the first type of processing, the regeneration,
is discussed further. The information that needs to be passed to
intermediate nodes consists of the type of regeneration, i.e., no
regeneration at this node or 1R, 2R or 3R Regeneration. In addition
the particular node may be a fixed or an optional regeneration point.
All in all, for regeneration at most an octet of information is
needed per intermediate node of an LSP. Assuming that this info is
carried in a TLV with reserved bits for extensibility we may
calculate with 8 octets. Due to the nature of regeneration, the
worst case is when all intermediate nodes are configured with
regeneration information.
2.2. OAM Configuration of Non-Intrusive Monitoring Entities
A Non-Intrusive Monitoring Entity (NIME) snoops the end-to-end
monitoring flow and may trigger consequent actions and invoke alarms.
To deploy a NIME, the end-to-end OAM configuration information must
be available and some NIME specific attributes may be set as well,
such as monitored signals and trigger thresholds.
Assuming that the end-to-end OAM configuration information is
available using the procedures described in [GMPLS-OAM-FWK], for a
specific NIME it is enough to encode the entity identifiers and
threshold parameters using TLVs based on [GMPLS-OAM-FWK] and the
appropriate technology specific drafts. For instance, in case of SDH
and OTN connection we may calculate with roughly 20 octets per NIME.
In worst case all intermediate nodes of an LSP can be configured as
NIMEs.
2.3. OAM Configuration of Tandem Connection Monitoring Entities
The Tandem Connection Monitoring Entity (TCME) is basically a pair of
MEPs running on a tandem connection, which is associated to the end-
to-end connection. Depending on the technology overlapping or
nesting TCMEs are allowed.
TCM is independent of the end-to-end monitoring flow, it multiplexes
its own monitoring flow on the connection. Hence the configuration
of TCM is basically similar to the configuration of end-to-end
monitoring, hence requiring the full configuration described in
[GMPLS-OAM-FWK], including MEP identifiers, message rates etc.
Therefore, specifying a TCME requires the same amount of
configuration data as the end-to-end OAM flow, plus the location
information of the two endpoints. Hence, we may calculate with
Kern & Takacs Expires September 2, 2010 [Page 4]
Internet-Draft Configuring middle nodes with RSVP-TE March 2010
roughly 100 octets per entity.
Kern & Takacs Expires September 2, 2010 [Page 5]
Internet-Draft Configuring middle nodes with RSVP-TE March 2010
3. RSVP-TE signaling alternatives
Two aspects need to be considered for each of the alternatives.
First, how a particular intermediate node is identified. Second, how
the configuration information is carried and used.
3.1. Using the LSP_ATTRIBUTES Object
The LSP_ATTRIBUTES Object [RFC5420] can accommodate TLVs to carry
configuration information for intermediate nodes as well. In order
to identify the nodes to which a specific configuration should be
applied the node identifiers must be explicitly listed. A crucial
problem here is that the list of nodes in the LSP_ATTRIBUTES Object,
the ERO and as a result of any distributed computation must be
synchronized. To this end, procedures that modify the path of the
LSP and/or the ERO must also revise TLVs in the LSP_ATTRIBUTES
Object.
3.2. Using the HOP_ATTRIBUTES Sub-Object in ERO
The ERO originally was designed to specify the route for a
connection, however over time this has been relaxed and the ERO now
carries resource configuration as well. For instance, one can
specify the downstream and upstream labels and declare a set of
unwanted/non-preferred resource parameters. These parameters are
listed as additional ERO Sub-Objects after the Sub-Object defining
the hop. To encode general configuration information a new ERO Sub-
Object can be defined (e.g., HOP_ATTRIBUTES [HOP-ATTR]), which would
allow inclusion of TLVs that contain specific attributes of the
intermediate hops of an LSP.
Since the ERO may contain loose hops and abstract nodes procedures
for intermediate node configuration must be prepared for the
appropriate resolution.
With this approach the binding of intermediate node configuration
information to the actual identification of the hop is naturally
solved.
3.3. Combination of LSP_ATTRIBUTES and ERO
The ERO could be used to identify that a specific hop has additional
configuration information, which is carried in the LSP_ATTRIBUTES
Object and point to that information element. In this case the ERO
would essentially contain an index to the contents of the
LSP_ATTRIBUTES Object. In this case the ERO is not overloaded with
configuration data, and in scenarios where the same configuration is
used at multiple intermediate hops the data that is carried in the
Kern & Takacs Expires September 2, 2010 [Page 6]
Internet-Draft Configuring middle nodes with RSVP-TE March 2010
path message is reduced.
3.4. Using multiple messages
Multiple message exchanges may be needed to remove scaling issues and
support general intermediate node configuration. However it must be
noted that not all use-cases will allow for the use of multiple
messages. In some cases it is mandatory that particular intermediate
nodes are configured together with path setup, hence configuration
information must be carried in the first Path message. This is
likely the case with WSON regeneration configuration. On the other
hand, there will be cases which may benefit from joint signaling with
the first Path message but where it may be also acceptable to use
multiple messages. This is likely the case with the setup of tandem
connection monitoring entities.
3.4.1. Multiple messages with semantic fragmentation
The problem of too much data in a single RSVP-TE message has been
faced with P2MP LSPs. In [RFC4875] the sub-state concept has been
introduced, where a PATH message may refer to a part of the signaling
state only, while the whole state is signaled with multiple PATH
messages.
For intermediate node configuration the fragmentation of information
could be considered. For instance, contents of the LSP_ATTRIBUTES
Object may be disseminated using several PATH messages. This would
allow stepwise configuration of functions, and so be a scalable way
to convey intermediate node configuration.
3.4.2. Using other signaling messages/procedures
The LSP is setup with RSVP-TE PATH and RESV messages, while
intermediate node configuration could be done with other RSVP
messages. This has been already applied to implement extra features
like collecting RSVP state information [RFC2745] or sending direct
notification to an intermediate node [RFC3473]. However, these
extensions do not carry configuration information that is included
into the RSVP state. How these states are refreshed need further
considerations.
Kern & Takacs Expires September 2, 2010 [Page 7]
Internet-Draft Configuring middle nodes with RSVP-TE March 2010
4. Discussion
For intermediate node configuration it is likely that two methods
will be needed.
One mechanism would support cases where path setup and intermediate
node configuration need to happen at the same time. In this case
only a very limited configuration of intermediate nodes would be
supported, i.e., through a set of flags or indexes. The simplest
method is to use the ERO and provide a placeholder for the
information.
The other mechanism would support complex configurations and to scale
may have to rely on multiple message exchanges. A solution based on
the semantic fragmentation described for P2MP LSPs may be a viable
solution.
Kern & Takacs Expires September 2, 2010 [Page 8]
Internet-Draft Configuring middle nodes with RSVP-TE March 2010
5. References
[GMPLS-OAM-FWK]
Takacs, A., Fedyk, D., and H. Jia, "OAM Configuration
Framework and Requirements for GMPLS RSVP-TE",
draft-ietf-ccamp-oam-configuration-fwk-03 (work in
progress), January 2010.
[HOP-ATTR]
Kern, A. and A. Takacs, "Encoding of Attributes of LSP
intermediate hops using RSVP-TE",
draft-kern-ccamp-rsvpte-hop-attributes-00 (work in
progress), October 2009.
[RFC2745] Terzis, A., Braden, B., Vincent, S., and L. Zhang, "RSVP
Diagnostic Messages", RFC 2745, January 2000.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
"Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A.
Ayyangarps, "Encoding of Attributes for MPLS LSP
Establishment Using Resource Reservation Protocol Traffic
Engineering (RSVP-TE)", RFC 5420, February 2009.
[WSON-FWK]
Bernstein, G., Lee, Y., and W. Imajuku, "Framework for
GMPLS and PCE Control of Wavelength Switched Optical
Networks (WSON)", draft-ietf-ccamp-rwa-wson-framework-05
(work in progress), February 2010.
[WSON-SIGNAL]
Bernstein, G., "Signaling Extensions for Wavelength
Switched Optical Networks",
draft-bernstein-ccamp-wson-signaling-06 (work in
progress), February 2010.
Kern & Takacs Expires September 2, 2010 [Page 9]
Internet-Draft Configuring middle nodes with RSVP-TE March 2010
Authors' Addresses
Andras Kern
Ericsson
Laborc u. 1.
Budapest, 1037
Hungary
Email: andras.kern@ericsson.com
Attila Takacs
Ericsson
Laborc u. 1.
Budapest, 1037
Hungary
Email: attila.takacs@ericsson.com
Kern & Takacs Expires September 2, 2010 [Page 10]