IETF A. Rhodes
Internet-Draft N. Neate
Intended status: Informational D. McWalter, Ed.
Expires: September 5, 2009 Data Connection Ltd
March 4, 2009
Problems observed with RSVP recovery signaling
draft-rhodes-rsvp-recovery-signaling-01.txt
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 5, 2009.
Copyright Notice
Copyright (c) 2009 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.
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
Rhodes, et al. Expires September 5, 2009 [Page 1]
Internet-Draft RSVP recovery signaling March 2009
material may not have granted the IETF Trust the right to allow
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
Implementation experience with RSVP-TE recovery signaling has
uncovered some problems. Associations between LSPs in different
sessions are forbidden. Protecting LSPs cannot themselves be
protected. Overlapping repairs cause loss of traffic. This draft
provides details of these problems for the community to consider.
Rhodes, et al. Expires September 5, 2009 [Page 2]
Internet-Draft RSVP recovery signaling March 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Association between LSPs in different sessions . . . . . . 4
3.2. LSP association in multi-domain protection cases . . . . . 4
3.3. Protecting LSPs cannot themselves be protected . . . . . . 4
3.4. Overlapping repairs cause loss of traffic . . . . . . . . 5
3.5. segment-recording-desired flag is unassigned . . . . . . . 5
4. Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Association between LSPs in different sessions . . . . . . 5
4.2. LSP association in multi-domain protection cases . . . . . 7
4.3. Protecting LSPs cannot themselves be protected . . . . . . 8
4.4. Overlapping repairs cause loss of traffic . . . . . . . . 8
4.5. segment-recording-desired flag is unassigned . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Revision History . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Changes in -01 . . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
9. Informative References . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Rhodes, et al. Expires September 5, 2009 [Page 3]
Internet-Draft RSVP recovery signaling March 2009
1. Introduction
This draft describes problems. It does not propose solutions.
Our purpose in writing this draft is to determine how to resolve some
RSVP-TE recovery problems we have encountered. We believe these
problems are due to limitations in existing RSVP signaling
procedures.
We would like the community to consider whether the following
scenarios are within the requirements for RSVP-TE protection. If so,
we would like comments on whether we have correctly interpreted the
existing RSVP-TE signaling proceduress in each case. If so, we
solicit further collaboration in preparing proposals for
interoperable solutions.
2. Terminology
GMPLS recovery terminology is introduced by [RFC4427].
'End-to-end protection' (e2e) procedures are defined by [RFC4872].
'Segment recovery' procedures are defined by [RFC4873].
3. Summary
3.1. Association between LSPs in different sessions
Segment recovery protecting LSPs may have a different endpoint
address from the corresponding protected LSP. The protected and
protecting LSPs are therefore in different Sessions. The Association
object of type 1 (recovery) is not effective in this case, as the
Association ID can only associate to an LSP ID within the same
Session.
3.2. LSP association in multi-domain protection cases
End-to-end protected LSPs may pass through several addressing
domains, resulting in mappings of addresses in the Session and
Sender-Template. This causes difficulties for LSP endpoints
attempting to associate protecting and protected LSPs.
3.3. Protecting LSPs cannot themselves be protected
End-to-end or segment protection can be applied to a protecting LSP.
That LSP is both protecting and protected. This cannot be signaled
Rhodes, et al. Expires September 5, 2009 [Page 4]
Internet-Draft RSVP recovery signaling March 2009
because only a single Protection object is allowed and it contains a
single bit to indicate whether the LSP is protecting or protected.
3.4. Overlapping repairs cause loss of traffic
Segment protection can be provided by two overlapping recovery paths.
A single failure may trigger restoration using both repairs. Traffic
is lost in this case.
3.5. segment-recording-desired flag is unassigned
[RFC4873] s5.2 defines this flag, but no value is given. We need to
ask IANA to assign a value.
4. Detail
4.1. Association between LSPs in different sessions
End-to-end recovery uses Association objects of type 1 (recovery) to
associate LSPs belonging to the same session. Association ID is (in
most cases) set to the LSP ID of the associated LSP. See [RFC4872]
s4.3, s6.1 and s16.
[RFC4873] s3.2 and s3.2.1 state that procedures for use of the
Association ID in segment recovery are not modified from those
defined in [RFC4872] for end-to-end recovery. The following example
shows that different procedures are necessary.
A G D
\ / \ /
\ / \ /
B-----C
/ \
/ \
E F
Protected LSP1: A-B-C-D, LSP ID 5
Protected LSP2: E-B-C-F, LSP ID 5
Segment recovery LSP1: B-G-C (1+1 protection)
Segment recovery LSP2: B-G-C (1+1 protection)
It is not possible for B and C to use LSP ID 5 to associate the two
segment recovery LSPs with the protected LSPs.
Discussion with authors suggests that it is intended that B assigns
an arbitrary value as the Association ID, although this is not
clearly spelled out. Here is how this applies to the example:
Rhodes, et al. Expires September 5, 2009 [Page 5]
Internet-Draft RSVP recovery signaling March 2009
Protected LSP1: A-B-C-D, LSP ID 5, Assoc ID 23
Protected LSP2: E-B-C-F, LSP ID 5, Assoc ID 24
Segment recovery LSP1: B-G-C (1+1 protection) Assoc ID 23
Segment recovery LSP2: B-G-C (1+1 protection) Assoc ID 24
This works in many cases, but introduces ambiguity when both segment
recovery and end-to-end recovery are used in a network.
?? protected LSP3: B-C, LSP ID 1, Assoc ID 25
Segment recovery LSP: B-G-C (1+1 protection) LSP ID 2, Assoc ID 25
End-to-end recovery LSP: B-G-C (1+1 protection) LSP ID 25, Assoc ID 1
It is not possible to decide which of these recovery LSPs protects
LSP3, at least not using existing procedures. The difficulty becomes
more marked as additional LSPs are added:
?? protected LSP3: B-C, LSP ID 1, Assoc ID 25
Segment protected LSP4: A-B-C-D, LSP ID 5, Assoc ID 1
?? recovery LSP5: B-G-C (1+1 protection) LSP ID 2, Assoc ID 25
?? recovery LSP6: B-G-C (1+1 protection) LSP ID 25, Assoc ID 1
(All Association objects are Type 1, Association Source B).
Significant analysis is required to determine which LSPs might be
associated, and which recovery LSPs are segment or end-to-end
recovery. In this case, we might choose to regard LSP3 as segment
protected by LSP5 rather than e2e protected by LSP6, as this allows
us to associate LSP4 with LSP6.
Such deductions may fail or prove incorrect where protected and
recovery LSPs are not 1:1 paired. Therefore we can expect to see
transient mapping errors as LSPs are established and released. We
can also expect to see permanent errors for recovery schemes such as
(Full) LSP rerouting that do not always pair protected and recovery
LSPs.
Two approaches to remove this difficulty have been suggested. Both
modify [RFC4873] procedures.
1. For a given Association Source, match Association objects by
first looking for a matching segment recovery Association ID. If
none exists, then match by treating Association ID as an LSP ID
within the given Session. This resolves the ambiguity but
restricts identifier use at the Association Source: values chosen
as segment recovery Association IDs are unusable as LSP IDs from
that source, and vice versa. A branch node implementing this
approach would not allow management to use the full range of LSP
IDs.
Rhodes, et al. Expires September 5, 2009 [Page 6]
Internet-Draft RSVP recovery signaling March 2009
2. Introduce a new Association type for segment recovery. Use
Association type 1 only for end-to-end recovery. This removes
the ambiguity. This keeps separate the LSP ID and Association ID
number spaces. The meaning of the Association ID is given by the
Association type. This is back-compatible with deployments of
[RFC4872] but disrupts deployments of [RFC4873].
4.2. LSP association in multi-domain protection cases
A GMPLS domain may contain multiple IP addressing domains. Therefore
an LSP may traverse multiple IP addressing domains. [RFC4927] and
[RFC5376] show inter-area and inter-AS (G)MPLS-TE tunnel
establishment.
A given IP address may occur in more than one area or AS. (Otherwise
the areas or ASes are not separate addressing domains). In order to
support this, address mappings must modify the Session and Sender-
Template at address domain boundaries.
Protected and protecting LSPs may achieve diversity by traversing
different domains. The cumulative modifications to Session and
Sender-Template may result in the LSPs being in different sessions at
the merge point.
........ ........... ........
. . . . . .
. A------B-----C------D .
. / . . . . \ .
. / . .....2..... . \ .
. I 1 3 E .
. \ . .....4..... . / .
. \ . . . . / .
. F------G-----H------J .
. . . . . .
........ ........... ........
In this illustration, four addressing domains (1-4) are shown.
Together they make up a GMPLS domain across which LSPs can be set up.
If two LSPs take the paths IABCDE and IFGHJE, then it is unclear
whether these LSPs can be considered to be in the same session at
node E.
A/B translates Tunnel Sender / ext tunnel ID from I to 'K'.
C/D translates Tunnel Sender / ext tunnel ID from K to 'L'.
F/G translates Tunnel Sender / ext tunnel ID from I to 'M'.
H/J translates Tunnel Sender / ext tunnel ID from M to 'N'.
So E may regard the LSPs as being in different sessions, as their
Rhodes, et al. Expires September 5, 2009 [Page 7]
Internet-Draft RSVP recovery signaling March 2009
extended tunnel ID will differ, as will their tunnel sender address
and any Association Source. These values were all set to 'I' in
addressing domain 1.
In such cases, the statement of [RFC4872] s6.1 that "both LSPs MUST
belong to the same session" is difficult to apply. End-to-end
protection might therefore not be applicable to a GMPLS domain
containing multiple IP addressing domains.
Applicability might be achieved if the GMPLS address mapping peformed
at IP addressing domain boundaries (AB, CD, FG, HJ) within a GMPLS
domain were to be specified or constrained. This is for discussion.
4.3. Protecting LSPs cannot themselves be protected
A segment recovery repair path can itself be protected by end-to-end
or segment recovery repairs, according to [RFC4873] s2. The result
is an LSP segment that is both protected and protecting.
However, only one protection object may be signaled. See [RFC4872]
s17 and [RFC4873] s7.
The (P)rotecting bit in the protection object should be set for the
LSP's protecting role, but clear for its protected role. See
[RFC4872] s4.2.1, s14.1 and [RFC4873] s6.1.
Therefore protecting LSPs cannot themselves be protected by repair
paths (unless we include non-interoperable procedures).
4.4. Overlapping repairs cause loss of traffic
Consider the following topology:
K-----------L
/ \
A===B===C===D===E===F===G===H
\ /
I-----------J
Primary bidirectional LSP A-B-C-D-E-F-G-H is protected by two
overlapping segment recovery paths B-K-L-F and C-I-J-G. Suppose 1:1
protection with extra traffic.
This 'overlapping protection' is a valid case, see [RFC4873] section
1.
Consider a failure of link D-E.
Rhodes, et al. Expires September 5, 2009 [Page 8]
Internet-Draft RSVP recovery signaling March 2009
K-----------L
/ \
A===B===C===D=X=E===F===G===H
\ /
I-----------J
D detects this locally, and sends Notify to C (first Notify object in
the received Path). C and G communicate to remove extra traffic from
the C-I-J-G repair, and then send and receive normal traffic on C-I
and G-J.
Meanwhile, E also detects the failure locally, and sends Notify to F
(first Notify object in the received Resv). F likewise communicates
with B and normal traffic is sent and received on B-K and F-L.
K----->-----L
/ \
A->-Bx<-C---D-X-E---F->xG<--H
\ /
I-----<-----J
Forward traffic reaches G on the link F-G. However, G has switched
to send and receive on G-J. Reverse traffic reaches B on C-B.
However, B has switched to send and receive on B-K.
Thus the standard procedure causes the loss of traffic in both
directions.
It may possible to solve this problem by configuring or otherwise
assigning master/slave roles to the branch and merge points. See
[RFC4426] s2.3. Currently there is no protocol description for how
the master/slave roles might be dynamically assigned, nor how
configured master/slave roles would affect [RFC4872] or [RFC4873]
switchover.
The mandatory procedures from [RFC4872] s6.2 and s7.2 (applied to
segment recovery by [RFC4873] s2.1) prescribe the behaviour of the
endpoints. It may be that procedures need to be modified so that
endpoints have some latitude to decide not to perform switchover in
some cases.
It is possible to detect the 'overlapping repairs' condition at nodes
B and G by using SRRO objects. These are optionally present between
F and H on the path, and between C and A on the Resv, see [RFC4873]
s2 and s5.2. In order to detect the problem reliably, procedures
would need to change to make them mandatory.
Rhodes, et al. Expires September 5, 2009 [Page 9]
Internet-Draft RSVP recovery signaling March 2009
4.5. segment-recording-desired flag is unassigned
[RFC4873] s5.2 assigns this flag as part of the SESSION_ATTRIBUTE
object. However, no request was made to IANA to assign a value for
it.
We could correct this omission by asking IANA to assign a value. At
the time of writing 0x40 is the next available value, see http://
www.iana.org/assignments/rsvp-te-parameters/rsvp-te-parameters.txt
Note that it is also open to specify that an LSP_ATTRIBUTE flag for
this purpose. For discussion.
5. Security Considerations
This document does not propose any protocol changes.
6. IANA Considerations
None.
7. Revision History
7.1. Changes in -01
Sections 3.1 and 4.1 better describe interactions between end-to-end
and segment recovery use of Association type 1 Association ID.
Sections 3.5 and 4.5 added, describing a missing codepoint.
Section 4.1 includes examples.
Section 4.1 includes Added Adrian Farrel's suggestion for egress to
match segment recovery associations in precedence to end-to-end
recovery associations.
Section 4.2 includes an example.
Section 4.2 questions the applicability of [RFC4872] to GMPLS domains
containing multiple IP addressing domains.
Section 4.4 notes that the SRRO object could provide a tool for
detecting overlapping repairs, though its presence is not mandatory.
Section 4.4 is updated with discussion of [RFC4426] roles, which do
Rhodes, et al. Expires September 5, 2009 [Page 10]
Internet-Draft RSVP recovery signaling March 2009
not appear to provide a solution.
8. Acknowledgements
The authors would like to thank all who have contributed to our
understanding of these issues, particularly Snigdho Bardalai, Adrian
Farrel, Remi Theillaud and Dimitri Papadimitriou.
9. Informative References
[RFC4426] Lang, J., Rajagopalan, B., and D. Papadimitriou,
"Generalized Multi-Protocol Label Switching (GMPLS)
Recovery Functional Specification", RFC 4426, March 2006.
[RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and
Restoration) Terminology for Generalized Multi-Protocol
Label Switching (GMPLS)", RFC 4427, March 2006.
[RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE
Extensions in Support of End-to-End Generalized Multi-
Protocol Label Switching (GMPLS) Recovery", RFC 4872,
May 2007.
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
"GMPLS Segment Recovery", RFC 4873, May 2007.
[RFC4927] Le Roux, J., "Path Computation Element Communication
Protocol (PCECP) Specific Requirements for Inter-Area MPLS
and GMPLS Traffic Engineering", RFC 4927, June 2007.
[RFC5376] Bitar, N., Zhang, R., and K. Kumaki, "Inter-AS
Requirements for the Path Computation Element
Communication Protocol (PCECP)", RFC 5376, November 2008.
Authors' Addresses
Andrew Rhodes
Data Connection Ltd
100 Church Street
Enfield EN2 6BQ
United Kingdom
Email: adr@dataconnection.com
Rhodes, et al. Expires September 5, 2009 [Page 11]
Internet-Draft RSVP recovery signaling March 2009
Nic Neate
Data Connection Ltd
100 Church Street
Enfield EN2 6BQ
United Kingdom
Email: nhn@dataconnection.com
David McWalter (editor)
Data Connection Ltd
100 Church Street
Enfield EN2 6BQ
United Kingdom
Email: dmcw@dataconnection.com
Rhodes, et al. Expires September 5, 2009 [Page 12]