One document matched: draft-martin-isis-local-protect-cap-02.txt

Differences from draft-martin-isis-local-protect-cap-01.txt

Network Working Group                                     C. Martin, Ed.
Internet-Draft                                        iPath Technologies
Expires: August 5, 2006                                    A. Atlas, Ed.
                                                            Google, Inc.
                                                                R. Torvi
                                                     Avici Systems, Inc.
                                                                D. Fedyk
                                                         Nortel Networks
                                                           February 2006


  ISIS Extensions to support U-turn Alternates for IP/LDP Fast-Reroute
                 draft-martin-isis-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 specifies additional information that can inserted in
   IS-IS LSPs to convey link capabilities that may be useful in certain
   applications.  In particular, an IS may convey that zero or more of



Martin, et al.           Expires August 5, 2006                 [Page 1]

Internet-Draft    draft-atlas-ip-local-protect-uturn-02    February 2006


   its links are explicit marked and/or implicit U-turn recipient
   capable, which may be described as capable of identifying traffic as
   U-turn traffic and redirecting the traffic to a suitable alternate.
   The immediate applicability for these two link capabilities is in
   support of local protection, provided by a U-turn alternate, in the
   event of a link and/or node failure while the IS-IS area is
   reconverging onto a new topology.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Signaling Link Capabilities . . . . . . . . . . . . . . . . . . 3
   3.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
   4.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6
   Intellectual Property and Copyright Statements  . . . . . . . . . . 7


































Martin, et al.           Expires August 5, 2006                 [Page 2]

Internet-Draft    draft-atlas-ip-local-protect-uturn-02    February 2006


1.  Introduction

   Recently, an increasing interest in IGP traffic engineering using
   intelligent metric assignment has led to the development and
   deployment of techniques and methods to manage traffic distribution
   and capacity expansion without explicit source routing [ref].  The
   fundamental premise to this approach is that it reduces operational
   complexity by leveraging existing and well-understood routing methods
   to achieve effectivey the same ends as are possible using explicit
   source routing, without adding any new technology to the routing
   system.  Many carriers have adopted this approach as a means to
   better manage bandwidth utilization and overall network efficiency.
   However, in many environments and under certain failure scenarios,
   the IGP TE approach does not allow for fast restoration, as the IGP
   must reconverge.  While fast IGP convergence is a topic of great
   interest, there is concern that a lower floor exists that, if
   crossed, may have a negative impact on the stability of a network.
   As the network diameter and node degree increase, this floor
   invariably raises in some proportionate manner - that is, the bigger
   the network, the slower the overall convergence.

   Depending on the application, restoration time-tolerance varies.  For
   real-time applications, it is certainly reasonable to expect
   restoration times in the <50 msec range.  The Fast Reroute method
   specified in [RFC4090] is one such mechanism to achieve these
   restoration times, as a precomputed alternate path can service the
   offered load that was destined for a failed link in a loop-free
   fashion.  However, this requires MPLS TE tunnels, which may not be a
   desirable option for reasons mentioned above - namely, the increase
   in complexity.

   [I-D.ietf-rtgwg-ipfrr-spec-base], [I-D.ietf-rtgwg-ipfrr-framework],
   and [U-TURN] have proposed an alternative to tunnel-based restoration
   in IP networks that is independent of MPLS.  Clearly, the ability to
   traffic engineer for bandwidth efficiency and fast restoration are
   attractive to network operators that are opposed to deploying MPLS-
   based RSVP-TE.  Nevertheless, the destination-based nature of the
   classical IP routing paradigm does not afford any guarantee that an
   alternate path around a failure is loop-free.  [U-TURN] proposes such
   a mechanism, however, this mechanism requires additional information
   to be distributed via IS-IS flooding so as to convey to routers in an
   area that the capability exists.


2.  Signaling Link Capabilities

   [RFC3784] defines extensions to IS-IS as specified in [IS-IS] and
   extended in [RFC1195] to allow for traffic engineering parameters to



Martin, et al.           Expires August 5, 2006                 [Page 3]

Internet-Draft    draft-atlas-ip-local-protect-uturn-02    February 2006


   be flooded throughout an area.  TLV 22, the extended IS-reachability
   TLV is used to add additional information about an IS's connections
   to other IS's, such as available bandwidth and color, by creating sub
   TLVs within TLV 22.  [I-D.ietf-isis-link-attr] introduces the notion
   of extending TLV 22, sub-TLV 19 to signal an IS's capabilities.  The
   initial capabilities proposed in [I-D.ietf-isis-link-attr] are
   orthogonal to the two proposed here; the "link excluded from local
   protection path" flag is also used for U-turn alternates [U-TURN].

   This draft proposes the creation of two new flags in TLV 22, Sub TLV
   19 for indicating an IS's ability to be a U-turn recipient.  The
   following bits are defined:

   0x6: Explicit Marked U-turn Recipient Capable: When this bit is set,
      an IS 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.
   0x7: Implicit U-turn Recipient Capable: When this bit is set, an IS
      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.


3.  Security Considerations

   This document does not introduce any new security issues.

4.  References

   [I-D.ietf-isis-link-attr]
              Vasseur, J. and S. Previdi, "Definition of an IS-IS Link
              Attribute sub-TLV", draft-ietf-isis-link-attr-01 (work in
              progress), May 2005.

   [I-D.ietf-rtgwg-ipfrr-framework]
              Shand, M. and S. Bryant, "IP Fast Reroute Framework",
              draft-ietf-rtgwg-ipfrr-framework-05 (work in progress),
              March 2006.

   [I-D.ietf-rtgwg-ipfrr-spec-base]
              Atlas, A. and A. Zinin, Ed., "Basic Specification for IP
              Fast-Reroute: Loop-free Alternates",



Martin, et al.           Expires August 5, 2006                 [Page 4]

Internet-Draft    draft-atlas-ip-local-protect-uturn-02    February 2006


              draft-ietf-rtgwg-ipfrr-spec-base-05.txt (work in
              progress), February 2006.

   [IS-IS]    "Intermediate System to Intermediate System Intra-Domain
              Routing Exchange Protocol for use in Conjunction with the
              Protocol for Providing the Connectionless-mode Network
              Service (ISO 8473)", ISO 10589.

   [RFC1195]  Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
              dual environments", RFC 1195, December 1990.

   [RFC3784]  Smit, H. and T. Li, "Intermediate System to Intermediate
              System (IS-IS) Extensions for Traffic Engineering (TE)",
              RFC 3784, June 2004.

   [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.





























Martin, et al.           Expires August 5, 2006                 [Page 5]

Internet-Draft    draft-atlas-ip-local-protect-uturn-02    February 2006


Authors' Addresses

   Christian Martin (editor)
   iPath Technologies

   Email: chris@ipath.net


   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


   Don Fedyk
   Nortel Networks
   600 Technology Park
   Billerica, MA  01821
   USA

   Phone: +1 978 288 3041
   Email: dwfedyk@nortelnetworks.com
















Martin, et al.           Expires August 5, 2006                 [Page 6]

Internet-Draft    draft-atlas-ip-local-protect-uturn-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.




Martin, et al.           Expires August 5, 2006                 [Page 7]