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

Versions: 00 01 02 03 RFC 5523

Internet Draft                         Lou Berger (LabN Consulting, LLC)
Category: Standards Track
Expiration Date: December 11, 2008

                                                           June 11, 2008

                OSPFv3 Based Layer 1 VPN Auto-Discovery

             draft-ietf-l1vpn-ospfv3-auto-discovery-00.txt

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/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on December 11, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   This document defines an Open Shortest Path First (OSPF) version 3
   based Layer-1 Virtual Private Network (L1VPN) auto-discovery
   mechanism.  This document parallels the existing OSPF version 2 L1VPN
   auto-discovery mechanism.  The notable functional difference is the
   support of IPv6.










Berger                       Standards Track                    [Page 1]

Internet-Draft draft-ietf-l1vpn-ospfv3-auto-discovery-00.txt June 11, 2008


Table of Contents

 1      Introduction  ..............................................   3
 1.1    Terminology  ...............................................   3
 1.2    Overview  ..................................................   4
 2      OSPFv3 L1VPN LSA and its TLVs  .............................   5
 2.1    OSPFv3 L1VPN LSA  ..........................................   5
 2.2    L1VPN IPv6 INFO TLV  .......................................   6
 3      OSPFv3 L1VPN LSA Advertising and Processing  ...............   8
 4      Backward Compatibility  ....................................   8
 5      Security Considerations  ...................................   9
 6      IANA Considerations  .......................................   9
 7      Acknowledgment  ............................................   9
 8      References  ................................................   9
 8.1    Normative References  ......................................   9
 8.2    Informative References  ....................................  10
 9      Authors' Addresses  ........................................  10
10      Full Copyright Statement  ..................................  10
11      Intellectual Property  .....................................  11











Berger                       Standards Track                    [Page 2]

Internet-Draft draft-ietf-l1vpn-ospfv3-auto-discovery-00.txt June 11, 2008


Conventions used in this document

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


1. Introduction

1.1. Terminology

   The reader of this document should be familiar with the terms used in
   [RFC4847] and [L1VPN-BM].  The reader of this document should also be
   familiar with [RFC2740], [OSPFv3-TE], and [L1VPN-OSPF].  In
   particular the following terms:

     L1VPN - Layer One Virtual Private Network

     CE -  Customer (edge) network element directly connected to the
           Provider network (terminates one or more links to one or more
           PEs); it is also connected to one or more Cs and/or other CEs

     C -  Customer network element that is not connected to the Provider
          network but is connected to one or more other Cs and/or CEs

     PE -  Provider (edge) network element directly connected to one or
           more Customer networks (terminates one or more links to one
           or more CEs associated with the same or different L1VPNs); it
           is also connected to one or more Ps and/or other PEs

     P -  Provider (core) network element that is not directly connected
          to any of Customer networks; P is connected to one or more
          other Ps and/or PEs

     LSA -  OSPF Link State Advertisement

     LSDB -  Link State Database: a data structure supported by an IGP
             speaker

     PIT -  Port Information Table

     CPI -  Customer Port Identifier

     PPI -  Provider Port Identifier







Berger                       Standards Track                    [Page 3]

Internet-Draft draft-ietf-l1vpn-ospfv3-auto-discovery-00.txt June 11, 2008


1.2. Overview

   The framework for Layer 1 VPNs is described in [RFC4847].  Basic mode
   operation is further defined in [L1VPN-BM].  [L1VPN-BM] identifies
   the information that is necessary to map customer information (port
   identifiers) to provider information (identifiers).  It also states
   that this mapping information may be provided via provisioning or via
   an auto-discovery mechanism.  [L1VPN-OSPF] provides such an auto-
   discovery mechanism using Open Shortest Path First (OSPF) version 2.
   This document provides the same functionality using of OSPF version 3
   and adds support for IPv6.

   Figure 1 shows the L1VPN basic service being supported using OSPF
   based L1VPN auto-discovery.  This figure shows two PE routers
   interconnected over a GMPLS backbone.  Each PE is attached to three
   CE devices belonging to three different Layer 1 VPNs.  In this
   network, OSPF is used to provide the VPN membership, port mapping and
   related information required to support basic mode operation.

                  PE                        PE
               +---------+             +--------------+
   +--------+  | +------+|             | +----------+ | +--------+
   |  VPN-A |  | |VPN-A ||             | |  VPN-A   | | |  VPN-A |
   |   CE1  |--| |PIT   ||  OSPF LSAs  | |  PIT     | |-|   CE2  |
   +--------+  | |      ||<----------->| |          | | +--------+
               | +------+| Distribution| +----------+ |
               |         |             |              |
   +--------+  | +------+|             | +----------+ | +--------+
   | VPN-B  |  | |VPN-B ||   -------   | |   VPN-B  | | |  VPN-B |
   |  CE1   |--| |PIT   ||--( GMPLS )--| |   PIT    | |-|   CE2  |
   +--------+  | |      ||  (Backbone) | |          | | +--------+
               | +------+|   --------  | +----------+ |
               |         |             |              |
   +--------+  | +-----+ |             | +----------+ | +--------+
   | VPN-C  |  | |VPN-C| |             | |   VPN-C  | | |  VPN-C |
   |  CE1   |--| |PIT  | |             | |   PIT    | |-|   CE2  |
   +--------+  | |     | |             | |          | | +--------+
               | +-----+ |             | +----------+ |
               +---------+             +--------------+

                 Figure 1: OSPF Auto-Discovery for L1VPNs

   The approach used in this document to provide OSPFv3 based L1VPN
   auto-discovery uses a new type of Link State Advertisement (LSA)
   which is referred to as an OSPFv3 L1VPN LSA.  The OSPFv3 L1VPN LSA
   carries information in TLV (type, length, value) structures.  An
   L1VPN specific TLV is defined below to propagate VPN membership and
   port information.  This TLV is is referred to as the L1VPN Info TLV.



Berger                       Standards Track                    [Page 4]

Internet-Draft draft-ietf-l1vpn-ospfv3-auto-discovery-00.txt June 11, 2008


   The OSPFv3 L1VPN LSA may also carry Traffic Engineering (TE) TLVs,
   see [RFC3630], [RFC4203], and [OSPFv3-TE].


2. OSPFv3 L1VPN LSA and its TLVs

   This section defines the OSPFv3 L1VPN LSA and its TLVs.


2.1. OSPFv3 L1VPN LSA

   The format of a OSPFv3 L1VPN LSA is 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           LS age              |          LS type              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Link State ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Advertising Router                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    LS sequence number                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        LS checksum           |             length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           L1VPN Info TLV                      |
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            TE Link TLV                        |
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   LS age
      As defined in [RFC2740].

   LS type
      As defined in [RFC2740].  The U-bit MUST be set to 1, and the
      S1 and S2 bits MUST be set to indicate either area or AS scoping.
      The LSA Function Code portion of this field MUST be set to TBA
      (by IANA), i.e., the OSPFv3 L1VPN LSA.

   Advertising Router
      As defined in [RFC2740].

   LS Sequence Number
      As defined in [RFC2740].




Berger                       Standards Track                    [Page 5]

Internet-Draft draft-ietf-l1vpn-ospfv3-auto-discovery-00.txt June 11, 2008


   LS checksum
      As defined in [RFC2740].

   Length
      As defined in [RFC2740].

   L1VPN Info TLV
      A single L1VPN Info TLV, as defined in section 2.2 of [L1VPN-OSPF]
      or section 2.2 of this document, MUST be present. If more than one
      L1VPN Info TLV is present, only the first TLV is processed and the
      others MUST be ignored on receipt.

   TE Link TLV
      A single TE Link TLV MAY be included in an OSPFv3 L1VPN LSA.
      When an L1VPN IPv4 Info TLV is present, a single TE Link TLV as
      defined in [RFC3630] and [RFC4203] MAY be included.  When an
      L1VPN IPv6 Info TLV is present, a single TE Link TLV as defined
      in [OSPFv3-TE] MAY be included.


2.2. L1VPN IPv6 INFO TLV

   The following TLV is introduced:

   Name: L1VPN IPv6 Info
   Type: 2
   Length: Variable
























Berger                       Standards Track                    [Page 6]

Internet-Draft draft-ietf-l1vpn-ospfv3-auto-discovery-00.txt June 11, 2008


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           L1VPN TLV Type      |         L1VPN TLV Length      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 L1VPN Globally Unique Identifier              |
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          PE TE Address                        |
   |                              ...                              |
   |                              ...                              |
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Link Local Identifier                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              |
   |                 L1VPN Auto-Discovery Information              |
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              .|           Padding             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   L1VPN TLV Type
      The type of the TLV (see above).

      TLV Length
      The length of the TLV in bytes, excluding the four (4) bytes
      of the TLV header and, if present, the length of the Padding
      field.

   L1VPN Globally Unique Identifier
      As defined in [L1VPN-BM].

   PE TE Address
      This field MUST carry an address that has been advertised by
      the LSA originator per [OSPFv3-TE] and is either the Router
      Address TLV or Local interface IP address link sub-TLV.  It will
      typically carry the TE Router Address.

   Link Local Identifier
      This field is used to support unnumbered links.  When an
      unnumbered PE TE link is represented, this field MUST contain
      a value advertised by the LSA originator per [RFC2740] in a
      Router LSA.  When a numbered link is represented, this field
      MUST be set to zero (0).

   L1VPN Auto-discovery information
      As defined in [L1VPN-BM].




Berger                       Standards Track                    [Page 7]

Internet-Draft draft-ietf-l1vpn-ospfv3-auto-discovery-00.txt June 11, 2008


   Padding
      A field of variable length and of sufficient size to ensure
      that the TLV is aligned on a four (4) byte boundary.  This
      field is only required when the L1VPN Auto-discovery
      information field is not four (4) byte aligned.  This field
      MUST be less than four (4) bytes long, and MUST NOT be present
      when the size of L1VPN Auto-discovery information field is
      four (4) byte aligned.


3. OSPFv3 L1VPN LSA Advertising and Processing

   PEs advertise local <CPI, PPI> tuples in OSPFv3 L1VPN LSAs containing
   L1VPN Info TLVs. Each PE MUST originate a separate OSPFv3 L1VPN LSA
   with AS flooding scope for each local CE-PE link. The LSA MUST be
   originated each time a PE restarts and every time there is a change
   in the PIT entry associated with a local CE-PE link. The LSA MUST
   include a single L1VPN Info TLV and MAY include a single TE Link TLV.
   The TE Link TLV carries TE attributes of the associated CE-PE link.
   Note that because CEs are outside of the provider TE domain, the
   attributes of CE-PE links are not advertised via normal OSPF-TE
   procedures as described in [OSPFv3-TE]. If more than one L1VPN Info
   TLVs and/or TE Link TLVs are found in the LSA, the subsequent TLVs
   SHOULD be ignored by the receiving PEs.

   Every time a PE receives a new, removed, or modified OSPFv3 L1VPN
   LSA, the PE MUST check whether it maintains a PIT associated with the
   L1VPN specified in the L1VPN Globally unique identifier field.  If
   this is the case (the appropriate PIT will be found if one or more
   local CE-PE links that belong to the L1VPN are configured), the PE
   SHOULD add, remove or modify the PIT entry associated with each of
   the advertised CE-PE links accordingly. (An implementation MAY choose
   to not remove or modify the PIT according to local policy or
   management directives.)  Thus, in the normal steady-state case, all
   PEs associated with a particular L1VPN will have identical local PITs
   for an L1VPN.


4. Backward Compatibility

   Neither the TLV nor the LSA introduced in this document present any
   interoperability issues. Per [RFC2740] and due to the U-bit being
   set, OSPFv3 speakers that do not support the OSPFv3 L1VPN LSA (Ps for
   example) just participate in the LSAs flooding process but should
   ignore the LSAs contents.






Berger                       Standards Track                    [Page 8]

Internet-Draft draft-ietf-l1vpn-ospfv3-auto-discovery-00.txt June 11, 2008


5. Security Considerations

   The approach presented in this document describes how PEs dynamically
   learn L1VPN specific information. Mechanisms to deliver the VPN
   membership information to CEs are explicitly out of scope of this
   document. Therefore, the security issues raised in this document are
   limited to within the OSPF domain.

   This defined approach reuses mechanisms defined in [RFC2740].
   Therefore the same security approaches and considerations apply to
   this approach.  OSPF provides several security mechanisms that can be
   applied.  Specifically, OSPF supports multiple types of
   authentication, limits the frequency of LSA origination and
   acceptance, and provides techniques to avoid and limit impact
   database overflow.  In cases were end-to-end authentication is
   desired, OSPF's neighbor-to-neighbor authentication approach can be
   augmented with an approach similar to the experimental extension to
   OSPF, see [RFC2154], which supports the signing and authentication of
   LSAs.


6. IANA Considerations

   Section 2.1 of this document requests the assignment of an OSPFv3 LSA
   Function Code, see http://www.iana.org/assignments/ospfv3-parameters.
   IANA is requested to make an assignment in the form:

       Value   OSPFv3 LSA type function Type            Reference
      -------  -----------------------------            ---------
          TBA  OSPFv3 L1VPN LSA                         [this document]

      A value of 13 is suggested for TBA.



7. Acknowledgment

   This document was created at the request of Pasi Eronen.  Adrian
   Farrel provided a valuable review of this draft.


8. References

8.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to indicate
             requirements levels", RFC 2119, March 1997.




Berger                       Standards Track                    [Page 9]

Internet-Draft draft-ietf-l1vpn-ospfv3-auto-discovery-00.txt June 11, 2008


   [RFC2740] R. Coltun, D. Ferguson, J. Moy, "OSPF for IPv6",
             RFC 2740.

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

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

   [L1VPN-BM] Fedyk, D., Rekhter, Y. (Eds.), "Layer 1 VPN Basic
              Mode", draft-ietf-l1vpn-basic-mode, work in progress.

   [L1VPN-OSPF] Bryskin, I., Berger, L., "OSPF Based Layer 1 VPN
                Auto-Discovery", work in progress,
                draft-ietf-l1vpn-ospf-auto-discovery.

   [OSPFv3-TE]  K. Ishiguro, T. Takada, "Traffic Engineering
                Extensions to OSPF version 3", work in progress,
                draft-ietf-ospf-ospfv3-traffic


8.2. Informative References

   [RFC2154] Murphy, S., Badger, M., Wellington, B., "OSPF with
             Digital Signatures", RFC 2154, June 1997.

   [RFC4847] Tomonori Takeda, Ed., "Framework and Requirements
             for Layer 1 Virtual Private Networks", RFC 4847,
             April 2007.


9. Authors' Addresses

   Lou Berger
   LabN Consulting, LLC
   Email: lberger@labn.net

10. Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.

   This document and the information contained herein are provided on an



Berger                       Standards Track                   [Page 10]

Internet-Draft draft-ietf-l1vpn-ospfv3-auto-discovery-00.txt June 11, 2008


   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 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.


11. Intellectual Property

   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.

Acknowledgement

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).















Berger                       Standards Track                   [Page 11]
Generated on: Wed Jun 11 14:41:46 EDT 2008


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/