[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Network Working Group                                         E. Osborne
Internet-Draft                                       Cisco Systems, Inc.
Intended status: Experimental                                  P. Psenak
Expires: February 5, 2012                                 Cisco Systems.
                                                          August 4, 2011


            Component and Composite Link Membership in OSPF
                         draft-ospf-cc-stlv-00

Abstract

   This document provides a TLV and sub-TLV for OSPF to establish a
   relationship between component and composite links in MPLS-TE opaque
   LSAs.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on February 5, 2012.

Copyright Notice

   Copyright (c) 2011 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents



Osborne & Psenak        Expires February 5, 2012                [Page 1]


Internet-Draft                   ospf-cc                     August 2011


   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Component TLV . . . . . . . . . . . . . . . . . . . . . . . . . 3
     2.1.  Removing link type and link ID sub-TLVs from C-TLV  . . . . 3
     2.2.  Inheritance between Link TLV and C-TLV  . . . . . . . . . . 3
     2.3.  Component/composite ID sub-TLV  . . . . . . . . . . . . . . 5
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
   6.  Normative References  . . . . . . . . . . . . . . . . . . . . . 6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6
































Osborne & Psenak        Expires February 5, 2012                [Page 2]


Internet-Draft                   ospf-cc                     August 2011


1.  Introduction

   Composite links [I-D.ietf-rtgwg-cl-requirement] require the ability
   to place MPLS-TE LSPs across specific components of a composite link.
   One way to do this is to advertise both the composite and components
   as links in the TE database using the mechanisms defined in
   [RFC3630].  In order to do this, a relationship must be established
   between a given composite link and its components.  This document
   provides a new top-level TLV to be advertised in the Traffic
   Engineering LSA.  This new TLV is necessary in order to ensure that
   bandwidth reserved from a given component link is properly accounted
   for at the component level, and to do so in a backward-compatible
   manner.  Along with this new top-level TLV, we define a sub-TLV to
   identify the composite link to which a component belongs.


2.  Component TLV

   The component TLV (C-TLV) is very similar to the Link TLV [RFC3630].
   The C-TLV defines a component link which belongs to a single
   composite.  A C-TLV MUST carry a CC-sTLV (see Section 2.3).  A C-TLV
   MUST NOT carry a Link Type or Link ID sub-TLV (see Section 2.1 for
   the rationale).  A C-TLV MUST otherwise follow all rules for sub-TLVs
   that pertain to a Link TLV.  In particular, all sub-TLVs which are
   defined for use in a Link TLV are usable in the C-TLV.

2.1.  Removing link type and link ID sub-TLVs from C-TLV

   RFC3630 requires that a Link TLV carry both a Link Type and Link ID
   sub-TLV.  The Link Type describes the link as either p2p or
   multiaccess.  Composite and component links are p2p by definition,
   and thus explicating this is unnecessary.  For p2p links the Link ID
   of the component is the Router ID of the neighbor at the other end;
   as all components of a composite terminate on the same node, the Link
   ID of the parent composite is inherited by the component link and
   thus does not need to be specified.

2.2.  Inheritance between Link TLV and C-TLV

   A component may or may not carry all of the sub-TLVs that its parent
   Link TLV does.  For example, a component may share an administrative
   group with its parent composite and thus can inherit the
   administrative group from the parent, or might not have an IP
   address.  This section specifies inheritance rules used to determine
   the value of various sub-TLVs inside the component link based on
   their status in the parent composite:

   Link type: per section 3.1, a C-TLV MUST NOT carry a Link Type sub-



Osborne & Psenak        Expires February 5, 2012                [Page 3]


Internet-Draft                   ospf-cc                     August 2011


   TLV.

   Link ID: per section 3.1, a C-TLV MUST NOT carry a Link ID sub-TLV.

   Local and remote interface IP addresses: if these are not specified
   in the parent composite link then they MAY be omitted from the
   component.  Practically speaking it is not useful to advertise a link
   without some sort of unique identifier, so it is expected that most
   implementations will advertise a parent link with some sort of
   identifier, either local/remote IP addresses or some other unique
   identifier such as Link Local and Remote Identifiers [RFC4203].  If a
   parent composite link carries a unique identifier a component link
   SHOULD also carry a unique identifier.  However, there is no
   requirement that the types match; a composite MAY advertise a Link
   Local/Remote Identifier while the component advertises local/remote
   IP addresses, or vice versa.  Deciding on the identifier used for a
   component link is outside the scope of this document and is
   implementation-specific.

   Traffic engineering metric: if this is not included in the C-TLV, it
   is inherited from the parent

   Maximum bandwidth: if this is specified in the parent composite it
   MUST be explicitly specified (that is, not inherited) in the
   component link.  If it is not specified in the parent it MAY be
   specified in the component.

   Maximum reservable bandwidth: if this is specified in the parent
   composite it MUST be explicitly specified (that is, not inherited) in
   the component link.  If it is not specified in the parent it MAY be
   specified in the component.

   Unreserved bandwidth: if this is specified in the parent composite it
   MUST be explicitly specified (that is, not inherited) in the
   component link.  If it is not specified in the parent it MAY be
   specified in the component.

   Administrative group: if this is not included in the C-TLV, it is
   inherited from the parent.

   Other sub-TLV types SHOULD follow a similar approach to the sub-TLVs
   listed here.  In general, the idea is that a component link should
   advertise any properties which are unique to that component and
   should inherit from the parent composite any properties which are
   shared between the parent composite and the component.






Osborne & Psenak        Expires February 5, 2012                [Page 4]


Internet-Draft                   ospf-cc                     August 2011


2.3.  Component/composite ID sub-TLV

   The association between a composite link and its components is made
   using the component/composite ID sub-TLV (CC-ID sTLV).  The CC-ID
   sTLV is a sub-TLV carried in both the Link TLV of the OSPF Opaque TE
   LSA and the C-TLV.  It is a 32-bit field (4 octets) defined as
   follows:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Composite ID                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Composite ID is a 32-bit value assigned to a composite on a given
   system.  The Composite ID MUST be unique to the advertising router.
   The method of assignment of the Composite ID is out of the scope of
   this document.

   When carried in a Link TLV, the Composite ID identifies that link as
   a composite link.  When carried in a C-TLV, the Composite ID
   identifies the composite link of which the given component is a
   member.  This association is necessary so that implementations which
   are component-aware can decide whether to establish an LSP over a
   composite or one of its components.  All components of a given
   composite MUST have an CC-ID sTLV, and the Composite ID of the
   composite and all of its components MUST match.  A link (component or
   composite) MUST contain only one CC-ID sTLV.  A node MAY advertise a
   composite link with no components, but if a node advertises any
   component links the node MUST also advertise an associated composite
   link.

   The CC-ID sTLV needs a number assigned to it by IANA.  For now, the
   sub-TLV number is TBD.


3.  IANA Considerations

   tbd


4.  Security Considerations

   There are no security considerations when using this sub-TLV; it is a
   link property like any other, and provides no more and no less
   exposure to security issues than the other sub-TLVs defined in
   [RFC3630].




Osborne & Psenak        Expires February 5, 2012                [Page 5]


Internet-Draft                   ospf-cc                     August 2011


5.  Acknowledgements

   Les Ginsberg, Padma Pilay-Esnault, Stefano Previdi, Tony Li, Abhay
   Roy


6.  Normative References

   [I-D.ietf-rtgwg-cl-requirement]
              Villamizar, C., McDysan, D., Ning, S., Malis, A., and L.
              Yong, "Requirements for MPLS Over a Composite Link",
              draft-ietf-rtgwg-cl-requirement-04 (work in progress),
              March 2011.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3630]  Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
              (TE) Extensions to OSPF Version 2", RFC 3630,
              September 2003.

   [RFC4203]  Kompella, K. and Y. Rekhter, "OSPF Extensions in Support
              of Generalized Multi-Protocol Label Switching (GMPLS)",
              RFC 4203, October 2005.


Authors' Addresses

   Eric Osborne
   Cisco Systems, Inc.
   300 Beaver Brook Road
   Boxborough, Massachusetts  01719


   Phone:
   Fax:
   Email: eosborne@cisco.com
   URI:













Osborne & Psenak        Expires February 5, 2012                [Page 6]


Internet-Draft                   ospf-cc                     August 2011


   Peter Psenak
   Cisco Systems.
   Mlynske Nivy 43
   Bratislava,   821 09
   Slovakia

   Phone:
   Fax:
   Email: eosborne@cisco.com
   URI:









































Osborne & Psenak        Expires February 5, 2012                [Page 7]