Network Working Group A. Atlas, Ed. Internet-Draft Avici Systems, Inc. Expires: April 24, 2005 October 24, 2004 U-turn Alternates for IP/LDP Fast-Reroute draft-atlas-ospf-local-protect-cap-01.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 April 24, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This document proposes an extension to OSPF Version 2 for advertising link capabilities using the extensions defined for traffic engineering. The link capabilities are defined there for future extensibility. To support the signaling requirements of U-turn alternates for IP Fast-Reroute, this document defines three bits in the proposed link capabilities extension. Atlas Expires April 24, 2005 [Page 1] Internet-Draft draft-atlas-ip-local-protect-uturn-01 October 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Link Capabilities sub-TLV . . . . . . . . . . . . . . . . . . 3 3. Interpretation for U-turn Alternates for IP Fast-Reroute . . . 4 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Editor's Address . . . . . . . . . . . . . . . . . . . . . . . 5 Contributing Authors' Addresses . . . . . . . . . . . . . . . 5 Intellectual Property and Copyright Statements . . . . . . . . 7 Atlas Expires April 24, 2005 [Page 2] Internet-Draft draft-atlas-ip-local-protect-uturn-01 October 2004 1. Introduction The motivations for an extension to OSPF version 2 to allow advertising link capabilities is to both allow the signaling required by [U-TURN] and to provide for future extensibility. [RFC3630] specifies OSPFv2 Traffic Engineering extensions for carrying link attributes, via a new Link TLV which is carried in the TE LSA. The Link TLV comprises of several sub-TLVs characterizing the links. Among those sub-TLVs are the Link ID and Link Type sub- TLVs, which are the only mandatory sub-TLVs. This is the set of information that is necessary to associated advertised link capabilities to the specific link. To avoid potentially unnecessary redundant advertisement of the Link ID and Link Type, in the event that a router needs to support signaling for both TE and link capabilities, this document proposes adding a Link Capabilities sub-TLV to the Link TLV. The Link Capabilities sub-TLV is defined and three bits are identified to support the signaling required by [U-TURN]. 2. Link Capabilities sub-TLV A new "Link Capabilities" sub-TLV is defined here to be carried in the "Link" TLV which uses the TE LSA [RFC3630]. The Link Capabilities field contains 32 flags, each indicating a different link capability. The following flags are defined: Bit Capability 0-3 Reserved 4 Eligible Alternate 5 Explicit Marked U-Turn Recipient Capable 6 Implicit U-Turn Recipient Capable 7-31 Future assignments Following is the format for Link-ID sub TLV: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 10 | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Capabilities | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Atlas Expires April 24, 2005 [Page 3] Internet-Draft draft-atlas-ip-local-protect-uturn-01 October 2004 3. Interpretation for U-turn Alternates for IP Fast-Reroute The OSPFv2 extensions described in this document define three bits which are relevant for determining the capabilities of a link in reference to U-turn Alternates for IP/LDP Fast-Reroute. If a link is advertised with a capability of "Eligible Alternate", then the router's neighbors are informed that the router considers whether that link can be used as an alternate next-hop. If a router's link is advertised as Implicit U-turn Recipient capable, then the advertising router can apply the implicit U-turn packet identification method[U-TURN] to identify packets as U-turn packets and redirect those U-turn packets towards an appropriate alternate next-hop, if such is available. A neighbor, which wishes to use this link as a U-turn alternate next-hop, should not mark traffic sent on the link into a U-turn alternate. If a router's link is advertised as Explicit Marked U-turn Recipient capable, then the advertising router can apply the explicitly marked U-turn packet identification method[U-TURN] to identify packets as U-turn packets and redirect those U-turn packets towards an appropriate alternate next-hop, if such is available. A neighbor, which wishes to use this link as a U-turn alternate next-hop, should mark traffic sent on the link into a U-turn alternate. 4. IANA Considerations A new sub-TLV in the Link TLV will need to be assigned by IANA; this is requested to be type 10, which is to be assigned via Standards Action [RFC3630]. The remaining bits in the Link Capabilities sub-TLV will need to be assigned by IANA. 5. Security Considerations This document does not introduce any new security issues. 6 References [FRAMEWORK] Shand, M., "IP Fast Reroute Framework", draft-ietf-rtgwg-ipfrr-framework-02.txt (work in progress), October 2004. [IPFRR] Atlas, A., "Basic Specification for IP Fast-Reroute: Loop-free Alternates", draft-ietf-rtgwg-ipfrr-spec-base-01.txt (work in progress), October 2004. Atlas Expires April 24, 2005 [Page 4] Internet-Draft draft-atlas-ip-local-protect-uturn-01 October 2004 [RFC3630] Katz, D., Kompella, K. and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. [U-TURN] Atlas, A., "U-turn Alternates for IP/LDP Fast-Reroute", draft-atlas-ip-local-protect-uturn-01.txt (work in progress), October 2004. Editor's Address Alia K. Atlas (editor) Avici Systems, Inc. 101 Billerica Avenue N. Billerica, MA 01862 USA Phone: +1 978 964 2070 EMail: aatlas@avici.com Contributing Authors' Addresses Raveendra Torvi Avici Systems 101 Billerica Avenue N. Billerica, MA 01862 USA Phone: +1 978 964 2026 EMail: rtorvi@avici.com Gagan Choudhury AT&T Room D5-3C21 200 Laurel Avenue Middletown, NJ 07748 USA EMail: gchoudhury@att.com Phone: +1 732 420-3721 Christian Martin Verizon 1880 Campus Commons Drive Reston, VA 20191 Atlas Expires April 24, 2005 [Page 5] Internet-Draft draft-atlas-ip-local-protect-uturn-01 October 2004 EMail: cmartin@verizon.com Brent Imhoff LightCore 14567 North Outer Forty Rd. Chesterfield, MO 63017 USA EMail: brent@lightcore.net Phone: +1 314 880 1851 Don Fedyk Nortel Networks 600 Technology Park Billerica, MA 01821 EMail: dwfedyk@nortelnetworks.com Phone: +1 978 288 3041 Atlas Expires April 24, 2005 [Page 6] Internet-Draft draft-atlas-ip-local-protect-uturn-01 October 2004 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 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 Internet Society (2004). 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. Atlas Expires April 24, 2005 [Page 7]