[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                            A. Kern
Internet-Draft                                                 A. Takacs
Intended status: Standards Track                                Ericsson
Expires: April 22, 2010                                 October 19, 2009


     Encoding of Attributes of LSP intermediate hops using RSVP-TE
               draft-kern-ccamp-rsvpte-hop-attributes-00

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 April 22, 2010.

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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.









Kern & Takacs            Expires April 22, 2010                 [Page 1]


Internet-Draft    Attributes for LSP hops Using RSVP-TE     October 2009


Abstract

   RFC5420 specifies a general framework to support signaling and
   reporting of generic attributes relevant for a signaled LSP.  This
   document extends the concept and defines a new Explicit Route
   subobject for RSVP-TE to allow the specification and reporting of
   attributes relevant to a particular hop of the signaled LSP.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Problem statement  . . . . . . . . . . . . . . . . . . . . . .  4
   3.  HOP_ATTRIBUTES subobject . . . . . . . . . . . . . . . . . . .  5
     3.1.  Format . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.2.  Processing HOP_ATTRIBUTES subobject  . . . . . . . . . . .  5
       3.2.1.  Processing rules for ERO embedding . . . . . . . . . .  5
       3.2.2.  Processing Rules for RRO embedding . . . . . . . . . .  6
   4.  IANA to Consider . . . . . . . . . . . . . . . . . . . . . . .  7
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10





























Kern & Takacs            Expires April 22, 2010                 [Page 2]


Internet-Draft    Attributes for LSP hops Using RSVP-TE     October 2009


1.  Introduction

   Generic encoding of LSP attributes is defined in [RFC5420].  It
   defines two objects: the LSP_ATTRIBUTES and the
   LSP_REQUIRED_ATTRIBUTES.  These two objects are designed to be
   flexible placeholders in order to carry general LSP related
   attributes.  The content of these new objects are processed by not
   only the endpoints, but may be interpreted by any intermediate node
   along the LSP.  This procedure allows intermediate nodes to access,
   extend or modify these attributes.

   The Explicit Route Object [RFC3209] allows the ingress node to
   partially or fully specify the route of an LSP.  The route is encoded
   as a sequence of hops that identifies a node or interface that must
   be crossed.  Further attributes assigned to each hop can be added to
   the route such as per-hop label control [RFC3473] and list of
   prohibited resources between two nodes [RFC4874].  These additional
   attributes are inserted into the ERO as subsequent subobjects and are
   relevant to the preceding hop describing subobject.
































Kern & Takacs            Expires April 22, 2010                 [Page 3]


Internet-Draft    Attributes for LSP hops Using RSVP-TE     October 2009


2.  Problem statement

   [RFC5420] primarily deals with attributes that are relevant to the
   whole LSP.  Currently, it is not possible to declare and signal
   attributes to a specific intermediate hop of the LSP.

   There are two straightforward options to signal attributes for
   intermediate hops:

   1.  Define a new HOP_ATTRIBUTES TLV in the LSP_REQUIRED_ATTRIBUTES
       Object, where sub-TLVs would identify hops (similarly as in the
       ERO) and specify attributes for that specific hop.  If attributes
       for multiple hops need to be specified, multiple hop identifying
       sub-TLVs can be used.

   2.  Introduce a new sub-object in the ERO to carry the attributes of
       the associated hop specified in the ERO.

   The first option detaches the encoding of the hop related attributes
   from route description (from the ERO).  This may create problems if
   for any reason the hops specified in the ERO and the hops identified
   in the LSP_REQUIRED_ATTRIBUTES Object get mismatched.  The second
   option binds the hop related attributes to the route description
   avoiding a possible mismatch of cross-references.

   In this document we introduce (2), i.e, a new ERO sub-object that
   encodes attributes relevant to a particular internal node or
   interface of the LSP.  To be extensible the objects consist of TLVs.























Kern & Takacs            Expires April 22, 2010                 [Page 4]


Internet-Draft    Attributes for LSP hops Using RSVP-TE     October 2009


3.  HOP_ATTRIBUTES subobject

   The HOP_ATTRIBUTES subobject can be inserted into route specifying
   and route recording objects specified for RSVP-TE: Explicit Route
   Object (ERO)/Secondary Explicit Route Object (SERO) and Record Route
   Object (RRO)/Secondary Record Route Object (SRRO); and it follows an
   IPv4 or IPv6 prefix or Unnumbered Interface ID subobject.  The
   carrying object provides the scope of the HOP_ATTRIBUTES subobject as
   well as processing rules of its content.  Regardless the carrying
   object, content of a HOP_ATTRIBUTES subobject is always relevant to
   the preceding hop encoding subobject.

   Note that the HOP_ATTRIBUTES subobject defines a new TLV space that
   is independent to the TLV space allocated in [RFC5420].

3.1.  Format

   HOP_ATTRIBUTES Type = 0x06 (IANA to assign), same value allocated in
   ERO and RRO TLV spaces.

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|    Type     |     Length    |        Reserved               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Attribute TLVs                             |
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.2.  Processing HOP_ATTRIBUTES subobject

3.2.1.  Processing rules for ERO embedding

   A HOP_ATTRIBUTES subobject follows an IPv4 or IPv6 prefix or
   Unnumbered Interface ID subobject.  The attributes carried in the
   HOP_ATTRIBUTES subobject is relevant to the associated (preceding)
   interface or node.

   A node that does not recognize the type of a TLV carried in the
   HOP_ATTRIBUTES object must reject the PATH message and issue a
   PATH_TEAR message with Error Code "Unknown HOP_ATTRIBUTE TLV" and the
   Error Value is set to the type code of the unknown TLV.

   When a node recognizes the TLV type code but does not support the
   attributes of that TLV, it must act according to the document
   describing the TLV.





Kern & Takacs            Expires April 22, 2010                 [Page 5]


Internet-Draft    Attributes for LSP hops Using RSVP-TE     October 2009


3.2.2.  Processing Rules for RRO embedding

   An intermediate node may want to notify the endpoints on e.g., hop
   related status information or values used/selected for specific
   attributes.  In this case the information to be reported is included
   in a HOP_ATTRIBUTES subobject, which is inserted into the RRO and
   follows an IPv4 or IPv6 prefix of an Unnumbered Interface ID
   subobject.











































Kern & Takacs            Expires April 22, 2010                 [Page 6]


Internet-Draft    Attributes for LSP hops Using RSVP-TE     October 2009


4.  IANA to Consider

   o  The HOP_ATTRIBUTES subobject can be inserted into any route
      describing objects specified for RSVP-TE: Explicit Route Object
      (ERO)/Secondary Explicit Route Object (SERO) and Record Route
      Object (RRO)/Secondary Record Route Object (SRRO).  A new type
      needs to be assigned for the HOP_ATTRIBUTES subobject, for both
      the ERO and RRO.  The suggested value is 0x06 (IANA to assign).

   o  The HOP_ATTRIBUTES subobject consist of TLVs; a new TLV space is
      required from which TLVs will be assigned.

   o  A node that does not recognize the type of a TLV carried in the
      HOP_ATTRIBUTES object must issue a PATH_TEAR message with Error
      Code "Unknown HOP_ATTRIBUTE TLV" (IANA to assign) and the Error
      Value is set to the type code of the unknown TLV.



































Kern & Takacs            Expires April 22, 2010                 [Page 7]


Internet-Draft    Attributes for LSP hops Using RSVP-TE     October 2009


5.  Security Considerations

   This document adds a new subobject to Explicit Route, Record Route
   and Secondary Explicit Route objects.  It does not introduce any new
   direct security issues than listed in [RFC5420].

   Any passing node may provide unauthorized access to the attributes
   relevant to downstream nodes and may alter the attributes.  Any
   passing node may provide unauthorized acces to the attribute or state
   information reported by any downstram node and may alter them.  This
   document does not provide solution for this issue, that could be
   handled through encoding and/or digitally signing the objects.







































Kern & Takacs            Expires April 22, 2010                 [Page 8]


Internet-Draft    Attributes for LSP hops Using RSVP-TE     October 2009


6.  References

   [RFC2205]  Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
              Functional Specification", RFC 2205, September 1997.

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, December 2001.

   [RFC3473]  Berger, L., "Generalized Multi-Protocol Label Switching
              (GMPLS) Signaling Resource ReserVation Protocol-Traffic
              Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.

   [RFC4874]  Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes -
              Extension to Resource ReserVation Protocol-Traffic
              Engineering (RSVP-TE)", RFC 4874, April 2007.

   [RFC5420]  Farrel, A., Papadimitriou, D., Vasseur, JP., and A.
              Ayyangarps, "Encoding of Attributes for MPLS LSP
              Establishment Using Resource Reservation Protocol Traffic
              Engineering (RSVP-TE)", RFC 5420, February 2009.





























Kern & Takacs            Expires April 22, 2010                 [Page 9]


Internet-Draft    Attributes for LSP hops Using RSVP-TE     October 2009


Authors' Addresses

   Andras Kern
   Ericsson
   Laborc u. 1.
   Budapest,   1037
   Hungary

   Email: andras.kern@ericsson.com


   Attila Takacs
   Ericsson
   Laborc u. 1.
   Budapest,   1037
   Hungary

   Email: attila.takacs@ericsson.com

































Kern & Takacs            Expires April 22, 2010                [Page 10]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/