Internet DRAFT - draft-ali-ccamp-lsp-inquiry
draft-ali-ccamp-lsp-inquiry
CCAMP Working Group Zafar Ali
Internet Draft George Swallow
Intended status: Standard Track Clarence Filsfils
Expires: August 17, 2013 Ori Gerstel
Matt Hartley
Cisco Systems
February 18, 2013
Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
Extension for Label Switched Path (LSP) Inquiry
draft-ali-ccamp-lsp-inquiry-00.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on August 15, 2013.
Copyright Notice
Copyright (c) 2012 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 Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
Ali, Swallow, Filsfils Expires August 2013 [Page 1]
Internet Draft draft-ali-ccamp-lsp-inquiry-00.txt
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Abstract
RSVP-TE reoptimization procedure for Packet Switch Capable (PSC)
tunnels and non-PSC tunnels has some differences. This document
highlights these differences, describes how existing procedures can
be used for reoptimization of non-PSC tunnels and proposes some
enhancements for reoptimization of non-PSC tunnels.
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 [RFC2119].
Table of Contents
1. Introduction .................................................. 2
1.1. Inquiry with Resource Locking.............................. 4
1.2. Inquiry without Resource Locking .......................... 5
2. RSVP-TE signaling procedure ................................... 6
2.1. RSVP-TE Signaling for Inquiry with Resource Locking ....... 6
2.2. RSVP-TE Signaling for Inquiry without Resource Locking .... 7
3. Security Considerations ....................................... 8
4. IANA Considerations ........................................... 8
4.1. RSVP Attribute Bit Flags .................................. 8
5. References
.................................................... 9
5.1. Normative References ...................................... 9
5.2. Informative References .................................... 9
1. Introduction
During reoptimization of PSC tunnel, existing and reoptimization
LPSs may use independent labels and may install independent
Ali, Swallow, Filsfils, et al Expires August 2013 [Page 2]
Internet Draft draft-ali-ccamp-lsp-inquiry-00.txt
forwarding states for each LSP. That is, existing and reoptimization
LSPs may be simultaneously active in both control and data planes.
However, for many non-PSC technologies label itself represents the
underlying physical resource and hence cannot be shared between
existing and reoptimization LSPs in the data plane. Consequently,
for many non-PSC technologies, reoptimization LSPs can only be
instantiated in the control plane. Furthermore, reoptimization LSP
is not immediately available to carry any traffic and requires
additional signaling for its activation in the data plane.
In this document, inquiry refers to a way to signal sharing of
resources (e.g., labels, links) between the existing and
reoptimization LSPs in the control plane without installing any
forwarding states in the data plane (e.g., without installing cross-
connections). In most non-PSC networks, inquiry step is required to
access feasibility and characteristics of the reoptimization LSP
before committing data plane resources and moving traffic to it.
This is especially true of scenarios when route computation is not
performed by ingress Label Edge Router (LER). These include (but are
not limited to):
. LSPs with loose hops in the Explicit Route Object (ERO), e.g.
inter-domain LSPs.
. Generalized Multi-Protocol Label Switching (GMPLS) User-
Network Interface (UNI) where route computation may be
performed by the (server layer) core Label Switch Router (LSR)
[RFC4208];
In such cases, ingress LER may like to inquire about feasibility and
attributes of a better path. Cost, TE metrics and SRLG values are
examples of attributes that ingress LER may like to inquire about
(e.g., before making a reoptimization decision). Procedures
specified in [ID.SRLG-RECORDING] and [ID.METRIC-RECORDING] may be
used for this purpose.
Reoptimization is an example where inquiry procedure is needed.
However, inquiry is also useful for other use cases, e.g., for
probing purposes. Hence, for the generalization purposes, LSP
signaled during inquiry is referred as inquiry LSP. Reoptimization
LSP is an example of inquiry LSP.
Ali, Swallow, Filsfils, et al Expires August 2013 [Page 3]
Internet Draft draft-ali-ccamp-lsp-inquiry-00.txt
Inquiry LSP may be signaled with or without resource locking in the
control plane. This is detailed in the following.
1.1. Inquiry with Resource Locking
Signaling inquiry LSP with resource locking is depicted in Figure
1. Specifically, Path message (Path1) is signaled such that
resource activation is Data Plane (DP) is skipped. However,
inquiry LSP reserves resources in the Control Plane (CP), i.e.,
resources/ labels are locked/ committed in the control plane.
Nonetheless, resources/ labels are still shared with the existing
LSP(s) belonging to the tunnel inquiry LSP belongs to.
| Path (Path1) | Path (Path1) | Path (Path1) |
| with resource | with resource | with resource |
| locking in CP | locking in CP | locking in CP |
| but without DP | but without DP | but without DP |
| activation | activation | activation |
|--------------->|--------------->|--------------->|
|<---------------|<---------------|<---------------|
| Resv (Resv1) | Resv (Resv1) | Resv (Resv1) |
| | | |
+-----------+
|Inquiry LSP|
|Passes |
|Evaluation |
+-----------+
| | | |
| Path Change | Path Change | Path Change |
| (Path2) | (Path2) | (Path2) |
| for DP | for DP | for DP |
| activation | activation | activation |
|--------------->|--------------->|--------------->|
|<---------------|<---------------|<---------------|
| Resv (Resv2) | Resv (Resv2) | Resv (Resv2) |
| | | |
Ingress LER LSR A LSR B Egress LER
Figure 1: Inquiry LSP Signaling with Resource Locking
By the time Resv1 for the initial Path message (Path1) is received
by the ingress LER, the ingress LER knows about feasibility and the
requested attributes of the inquiry LSR. Please note that to ensure
resource locking at the right priority, inquiry LSP needs to be
signaled using the same setup and hold priority as existing LSP.
After finding feasibility and the requested attributes of the
inquiry LSP, the ingress LER evaluates inquiry LSP. E.g., if the
inquiry LSP is signaled for reoptimization purposes, the ingress LER
Ali, Swallow, Filsfils, et al Expires August 2013 [Page 4]
Internet Draft draft-ali-ccamp-lsp-inquiry-00.txt
determines if it would like to reoptimize the existing LSP. If
ingress LER decides not to reoptimize existing LSP, it deletes the
inquiry LSP (by sending Path tear message -
- this option is not shown
in Figure 1). However, if the ingress LER decides to reoptimize the
tunnel to use the inquire LSP, it initiates activation of the
inquiry LSP in the data plane (as shown by Path2 and Resv2 signaling
loop in Figure 1). How ingress LER moves traffic from existing LSP
to inquire LSP for reoptimization purpose is beyond the scope of
this document.
1.2. Inquiry without Resource Locking
When inquiry is performed with resource locking, the resources used
by the inquiry LSP are locked in control plane and cannot be used by
any LSP other than the LSP(s) belonging to the same tunnel (of
course resource preemption based on setup and hold priority of the
inquiry LSP is still possible). This limits network availability in
the event of a failure, especially when inquiry is used frequently,
e.g., for probing purposes. This issue can be addressed by signaling
inquiry LSP without resource locking. In this case, the resources
used by the inquiry LSP are not locked in control plane and can be
used by any LSP, including the existing LSP(s) belonging to the same
tunnel. Therefore, if inquiry LSP is signaled without resource
locking, additional signaling is required to first lock the
resources in the control plane, before the LSP can be activated in
the data plane. This is depicted in the following Figure.
| Path (Path1) | Path (Path1) | Path (Path1) |
|without resource|without resource|without resource|
| locking in CP | locking in CP | locking in CP |
| and without DP | and without DP | and without DP |
| activation | activation | activation |
|--------------->|--------------->|--------------->|
|<---------------|<---------------|<---------------|
| Resv (Resv1) | Resv (Resv1) | Resv (Resv1) |
| | | |
+-----------+
|Inquiry LSP|
|Passes |
|Evaluation |
+-----------+
| | | |
| Path Change | Path Change | Path Change |
| (Path2) | (Path2) | (Path2) |
| for resource | for resource | for resource |
| locking in CP | locking in CP | locking in CP |
|--------------->|--------------->|--------------->|
|<---------------|<---------------|<---------------|
| Resv (Resv2) | Resv (Resv2) | Resv (Resv2) |
| | | |
Ali, Swallow, Filsfils, et al Expires August 2013 [Page 5]
Internet Draft draft-ali-ccamp-lsp-inquiry-00.txt
| | | |
| Path Change | Path Change | Path Change |
| (Path3) | (Path3) | (Path3) |
| for DP | for DP | for DP |
| activation | activation | activation |
|--------------->|--------------->|--------------->|
|<---------------|<---------------|<---------------|
| Resv (Resv3) | Resv (Resv3) | Resv (Resv3) |
| | | |
Ingress LER LSR A LSR B Egress LER
Figure 2: Inquiry LSP Signaling without Resource Locking
Initial Path message (Path1) is signaled such that resource locking
in control plane and resource activation is data plane is skipped.
By the time Resv1 for the initial Path message (Path1) is received
by the ingress LER, the ingress LER knows about feasibility and the
requested attributes of the inquiry LSR. The inquiry LSP evaluation
process works in the same fashion as discussed in Section 1.1.
As Path1 is signaled without resource locking, there is no guarantee
that the resources for the inquiry LSP will be available when
ingress LER decides to activate the inquiry LSP. Therefore, the
ingress LER first signals a path change (Path2) to lock the resource
in the control plane before inquiry LSP can be activated in the data
plane.
2. RSVP-TE signaling procedure
This section describes the signaling procedure for LSP inquiry with
and without resource locking.
2.1. RSVP-TE Signaling for Inquiry with Resource Locking
[RFC6001] specifies procedure for signaling Soft Forwarding
Adjacency (Soft FA). It defines the Pre-Planned LSP flag in the
Attribute Flags TLV, which can be carried in an LSP_ATTRIBUTES
object defined in [RFC5420]. The Pre-Planned LSP flag can also be
used to signal inquiry LSP with resource locking.
The processing rules for the Pre-Planned LSP flag are unchanged
from [RFC6001]. The procedures for the processing the Attribute
Flags TLV are also unchanged from [RFC5420]. The following
description is provided to help describe usage of the Pre-Planned
LSP flag in the context of signaling the inquiry LSP. Example of
Figure 1 is used to describe the usage.
Ali, Swallow, Filsfils, et al Expires August 2013 [Page 6]
Internet Draft draft-ali-ccamp-lsp-inquiry-00.txt
. Path1 message in Figure 1 is sent with the Pre-Planned LSP
flag set to 1. As per [RFC6001], this enables provisioning
of inquiry LSP in control plane only. In order to enable
sharing if resources within the same tunnel, Path1 message
is sent with shared explicit reservation style [RFC3209].
. In order to activate inquiry LSP in the data plane, Path2
message (please see Figure 1) is sent with the Pre-Planned
LSP flag set to 0.
2.2. RSVP-TE Signaling for Inquiry without Resource Locking
In order to indicate signaling of an LSP without resource
provisioning in neither control plane nor data plane, a new flag
in the Attribute Flags TLV, which can be carried in an
LSP_ATTRIBUTES Object, is defined as follows:
. Pre-Planned LSP Without Resource Locking flag (to be
assigned by IANA, recommended bit position TBD)
The Pre-Planned LSP Without Resource Locking flag is
meaningful on a Path message. The procedure for the processing
the Attribute Flags TLV follows [RFC5420]. The flag is used as
described in the following.
. If the Pre-Planned LSP Without Resource Locking flag is set
to 1, the transit nodes SHOULD NOT reserve resources
required by the LSP in the control plane and MUST NOT
install any forwarding states associated with the LSP in the
data plane. However, all LERs and LSRs are required to
remember the resource (labels, links, etc.) assignments and
the RSVP-TE states associated with this LSP. These resources
are not locked and hence can be claimed by anther LSP. If
the Pre-Planned LSP Without Resource Locking flag is set to
1, the Pre-Planned LSP flag MUST be ignored. In our example
of Figure 2, Path1 message is sent with the Pre-Planned LSP
Without Resource Locking flag set to 1.
. If the Pre-Planned LSP Without Resource Locking flag is set
to 0 and the Pre-Planned LSP flag is set to 1, the transit
nodes MUST commit resources associated with the LSP in the
control plane. However, if a resource is already claimed by
another LSP, the processing LSR/ LER MUST send a Path Error
with code: "Admission Control Failure (1)" and subcode "LSP
Admission Failure (4) and Path State Removal flag. A
Ali, Swallow, Filsfils, et al Expires August 2013 [Page 7]
Internet Draft draft-ali-ccamp-lsp-inquiry-00.txt
processing LSR/ LER MUST NOT install any forwarding states
associated with the LSP in the data plane. Path2 message in
Figure 2 is sent with the Pre-Planned LSP Without Resource
Locking flag set to 0 and the Pre-Planned LSP flag is set to
1. It is RECOMMENDED that no other modifications be made to
other RSVP objects during this operation (signaling Path2).
. Activation of LSP in data plane follows the procedure
specific in [RFC6001]. E.g., Path2 message in Figure 2 is
sent with the Pre-Planned LSP flag set to 0.
3. Security Considerations
This document does not introduce any additional security issues
above those identified in [RFC5920], [RFC2205], [RFC3209], and
[RFC3473] and [RFC4874].
4. IANA Considerations
4.1. RSVP Attribute Bit Flags
The IANA has created a registry and manages the space of
attributes bit flags of Attribute Flags TLV as described in
section 11.3 of [RFC5420]. It is requested that the IANA makes
assignments from the Attribute Bit Flags defined in this
document.
This document introduces the following new Attribute Bit Flag:
- Bit number: TBD
- Defining RFC: this I-D
- Name of bit: Pre-Planned LSP Without Resource Locking
Flag
Ali, Swallow, Filsfils, et al Expires August 2013 [Page 8]
Internet Draft draft-ali-ccamp-lsp-inquiry-00.txt
5. References
5.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
LSP Tunnels", RFC 3209, December 2001.
[RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K.,
Brungard, D., and JL. Le Roux, "Generalized MPLS
(GMPLS) Protocol Extensions for Multi-Layer and Multi-
Region Networks (MLN/MRN)", RFC 6001, October 2010.
[RFC5420] Farrel, A., Ed., 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.
5.2. Informative References
[ID.SRLG-RECORDING] F. Zhang, D. Li, O. Gonzalez de Dios, C.
Margaria, "RSVP-TE Extensions for Collecting SRLG
Information", draft-ietf-ccamp-rsvp-te-srlg-
collect.txt, work in progress.
[ID.TE-METRIC-RECORDING] Ali, Z., Swallow, G., Filsfils, C., et
al "RSVP-TE extension for recording TE Metric of a
Label Switched Path", draft-ali-ccamp-te-metric-
recording, work in progress.
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
"Generalized Multiprotocol Label Switching (GMPLS)
User-Network Interface (UNI): Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Support for the
Overlay Model", RFC 4208, October 2005.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January
2003.
Ali, Swallow, Filsfils, et al Expires August 2013 [Page 9]
Internet Draft draft-ali-ccamp-lsp-inquiry-00.txt
[RFC2209] Braden, R. and L. Zhang, "Resource ReSerVation Protocol
(RSVP) -- Version 1 Message Processing Rules", RFC
2209, September 1997.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.
Authors' Addresses
Zafar Ali
Cisco Systems.
Email: zali@cisco.com
George Swallow
Cisco Systems
swallow@cisco.com
Clarence Filsfils
Cisco Systems, Inc.
cfilsfil@cisco.com
Ori Gerstel
Cisco Systems
Email: ogerstel@cisco.com
Matt Hartley
Cisco Systems
Email: mhartley@cisco.com
Ali, Swallow, Filsfils, et al Expires August 2013 [Page 10]