Network Working Group A. Atlas, Ed. Internet-Draft Google Inc. Expires: August 5, 2006 R. Torvi Avici Systems, Inc. G. Choudhury AT&T Juniper Networks D. Fedyk Nortel Networks February 2006 OSPFv2 Extensions for Link Capabilities to support U-turn Alternates for IP/LDP Fast-Reroute draft-atlas-ospf-local-protect-cap-02 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 August 5, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document proposes an extension to OSPF Version 2 for advertising Atlas, et al. Expires August 5, 2006 [Page 1] Internet-Draft draft-atlas-ospf-local-protect-cap-02 February 2006 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. 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 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Intellectual Property and Copyright Statements . . . . . . . . . . 8 Atlas, et al. Expires August 5, 2006 [Page 2] Internet-Draft draft-atlas-ospf-local-protect-cap-02 February 2006 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-1 Reserved 2 Link excluded from local protection path 3-4 Reserved 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, et al. Expires August 5, 2006 [Page 3] Internet-Draft draft-atlas-ospf-local-protect-cap-02 February 2006 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 as "link excluded from local protection path", then the router's neighbors are informed that the router considers whether that link cannot be used as an alternate next-hop. For other applications, such as RSVP-TE FRR [RFC4090], this means the link SHOULD not be included in any computation of a repair path by any other router in the routing area. 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 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. Atlas, et al. Expires August 5, 2006 [Page 4] Internet-Draft draft-atlas-ospf-local-protect-cap-02 February 2006 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. [U-TURN] Atlas, A., Ed., "U-turn Alternates for IP/LDP Fast- Reroute", draft-atlas-ip-local-protect-uturn-03.txt (work in progress), February 2006. Atlas, et al. Expires August 5, 2006 [Page 5] Internet-Draft draft-atlas-ospf-local-protect-cap-02 February 2006 Authors' Addresses Alia K. Atlas (editor) Google Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 USA Email: akatlas@alum.mit.edu Raveendra Torvi Avici Systems, Inc. 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 Phone: +1 732 420 3721 Email: gchoudhury@att.com Brent Imhoff Juniper Networks 1194 North Mathilda Sunnyvale, CA 94089 USA Phone: +1 314 378 2571 Email: bimhoff@planetspork.com Atlas, et al. Expires August 5, 2006 [Page 6] Internet-Draft draft-atlas-ospf-local-protect-cap-02 February 2006 Don Fedyk Nortel Networks 600 Technology Park Billerica, MA 01821 USA Phone: +1 978 288 3041 Email: dwfedyk@nortelnetworks.com Atlas, et al. Expires August 5, 2006 [Page 7] Internet-Draft draft-atlas-ospf-local-protect-cap-02 February 2006 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 (2006). 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, et al. Expires August 5, 2006 [Page 8]