IETF A. Rhodes
Internet-Draft N. Neate
Expires: February 7, 2009 D. McWalter, Ed.
Data Connection Ltd
August 6, 2008
Problems observed with RSVP recovery signaling
draft-rhodes-rsvp-recovery-signaling-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 February 7, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
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 February 7, 2009 [Page 1]
Internet-Draft RSVP recovery signaling August 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1 Association between LSPs in different sessions . . . . . . 3
3.2 LSP association in multi-domain protection cases . . . . . 3
3.3 Protecting LSPs cannot themselves be protected . . . . . . 3
3.4 Overlapping repairs cause loss of traffic . . . . . . . . 4
4. Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1 Association between LSPs in different sessions . . . . . . 4
4.2 LSP association in multi-domain protection cases . . . . . 4
4.3 Protecting LSPs cannot themselves be protected . . . . . . 4
4.4 Overlapping repairs cause loss of traffic . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1 Normative References . . . . . . . . . . . . . . . . . . . 6
8.2 Informative References . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . 8
Rhodes, et al. Expires February 7, 2009 [Page 2]
Internet-Draft RSVP recovery signaling August 2008
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 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
because only a single Protection object is allowed and it contains a
single bit to indicate whether the LSP is protecting or protected.
Rhodes, et al. Expires February 7, 2009 [Page 3]
Internet-Draft RSVP recovery signaling August 2008
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.
4. Detail
4.1 Association between LSPs in different sessions
Association objects of type 1 (recovery) always associate LSPs
belonging to the same session ([RFC4872] s6.1, [RFC4873] s3).
Segment recovery repair paths must use the endpoint specified by
explicit or dynamic control procedures ([RFC4873] s4.2 and s6.2).
In cases where the recovery path endpoint differs from the protected
LSP endpoint, it is not possible to satisfy these restrictions.
As a result, segment recovery repair paths are not effective in these
cases (unless non-interoperable assumptions are made).
4.2 LSP association in multi-domain protection cases
LSPs may traverse multiple IP addressing domains. Address mappings
may modify the Session and Sender-Template at domain boundaries.
Protected and protecting LSPs may achieve diversity by traversing
different domains. The modifications to Session and Sender-Template
may result in the LSPs being in different sessions at the end of the
repair path.
In this case, the Association ID in the Association object cannot be
used to associate the protecting and protected LSPs: The
restrictions of [RFC4872] s6.1 and those of [RFC4873] s3 prevent the
association of LSPs in different sessions.
As a result, end-to-end recovery repair paths are not effective in
these cases (unless non-interoperable assumptions are made).
4.3 Protecting LSPs cannot themselves be protected
Only one protection object may be signaled. See [RFC4872] s17 and
[RFC4873] s7.
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.
Rhodes, et al. Expires February 7, 2009 [Page 4]
Internet-Draft RSVP recovery signaling August 2008
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.
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
Rhodes, et al. Expires February 7, 2009 [Page 5]
Internet-Draft RSVP recovery signaling August 2008
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.
The standard procedure causes the loss of traffic in both directions.
5. Security Considerations
This document does not propose any protocol changes.
6. IANA Considerations
None.
7. Acknowledgements
Thanks to all reviewers, including Snigdho Bardalai and Remi
Theillaud.
Differing interpretations of RSVP signaling procedures confirmed that
we should circulate this draft.
8. References
8.1 Normative References
8.2 Informative References
[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.
Rhodes, et al. Expires February 7, 2009 [Page 6]
Internet-Draft RSVP recovery signaling August 2008
Authors' Addresses
Andrew Rhodes
Data Connection Ltd
100 Church Street
Enfield EN2 6BQ
United Kingdom
Email: adr@dataconnection.com
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 February 7, 2009 [Page 7]
Internet-Draft RSVP recovery signaling August 2008
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The IETF Trust (2008). This document is subject to the
rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Rhodes, et al. Expires February 7, 2009 [Page 8]