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

Versions: (draft-bryskin-l1vpn-ospf-auto-discovery) 00 01 02 03 04 05 06 RFC 5252

Internet Draft                    Igor Bryskin (ADVA Optical Networking)
Category: Standards Track              Lou Berger (LabN Consulting, LLC)
Expiration Date: November 13, 2008

                                                            May 13, 2008

                 OSPF Based Layer 1 VPN Auto-Discovery

              draft-ietf-l1vpn-ospf-auto-discovery-06.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 November 13, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   This document defines an Open Shortest Path First (OSPF) based
   Layer-1 Virtual Private Network (L1VPN) auto-discovery mechanism.
   This mechanism enables provider edge (PE) devices using OSPF to
   dynamically learn about existence of each other, and attributes of
   configured customer edge (CE) links and their associations with
   L1VPNs.  This document builds on L1VPN framework and requirements,
   and provides a L1VPN basic mode auto-discovery mechanism.








Bryskin & Berger             Standards Track                    [Page 1]

Internet-Draft draft-ietf-l1vpn-ospf-auto-discovery-06.txt   May 13, 2008


Table of Contents

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











Bryskin & Berger             Standards Track                    [Page 2]

Internet-Draft draft-ietf-l1vpn-ospf-auto-discovery-06.txt   May 13, 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 [RFC2328], [2370BIS], and [RFC3630].  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 PR 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





Bryskin & Berger             Standards Track                    [Page 3]

Internet-Draft draft-ietf-l1vpn-ospf-auto-discovery-06.txt   May 13, 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] document
   identifies the information that is necessary to map customer
   information (ports identifiers) to provider information
   (identifiers).  It also states that this mapping information may be
   provided via provisioning or via an auto-discovery mechanism.  This
   document provides such an auto-discovery mechanism using Open
   Shortest Path First (OSPF) version 2.  Use of OSPF version 3 and
   support for IPv6 are out of scope of this document and will be
   defined separately.

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

   See [L1VPN-BGP] for a parallel L1VPN auto-discovery that uses BGP.
   The OSPF approach described in this document is particularly useful
   in networks where BGP is not typically used.

   The approach used in this document to provide OSPF based L1VPN auto-



Bryskin & Berger             Standards Track                    [Page 4]

Internet-Draft draft-ietf-l1vpn-ospf-auto-discovery-06.txt   May 13, 2008


   discovery uses a new type of Opaque Link State Advertisement (LSA)
   which is referred to as an L1VPN LSA.  The 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.  The
   L1VPN LSA may also carry Traffic Engineering (TE) TLVs, see [RFC3630]
   and [RFC4203].


2. L1VPN LSA and its TLVs

   This section defines the L1VPN LSA and its TLVs.


2.1. L1VPN LSA

   The format of a 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             |     Options   |  LS Type      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Opaque Type  |               Opaque ID                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Advertising Router                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      LS Sequence Number                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         LS checksum           |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           L1VPN Info TLV                      |
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            TE Link TLV                        |
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   LS age
      As defined in [RFC2328]

   Options
      As defined in [RFC2328].

   LS Type
      This field MUST be set to 11, i.e., an Autonomous System (AS)
      scoped Opaque LSA [2370BIS].




Bryskin & Berger             Standards Track                    [Page 5]

Internet-Draft draft-ietf-l1vpn-ospf-auto-discovery-06.txt   May 13, 2008


   Opaque Type
      The value of this field MUST be set to TBA (by IANA).

   Opaque ID
      As defined in [2370BIS].

   Advertising Router
      As defined in [RFC2328].

   LS Sequence Number
      As defined in [RFC2328].

   LS checksum
      As defined in [RFC2328].

   Length
      As defined in [RFC2328].

   L1VPN Info TLV
      A single TLV, as defined in section 3.2, 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 (as defined in [RFC3630] and [RFC4203])
      MAY be included in a L1VPN LSA


2.2. L1VPN INFO TLV

   The following TLV is introduced:

   Name: L1VPN IPv4 Info
   Type: 1
   Length: Variable
















Bryskin & Berger             Standards Track                    [Page 6]

Internet-Draft draft-ietf-l1vpn-ospf-auto-discovery-06.txt   May 13, 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.

   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 [RFC3630] 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 [RFC4203] in a
      Link Local/Remote Identifiers link sub-TLV.  When a numbered
      link is represented, this field MUST be set to zero (0).

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






Bryskin & Berger             Standards Track                    [Page 7]

Internet-Draft draft-ietf-l1vpn-ospf-auto-discovery-06.txt   May 13, 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. L1VPN LSA Advertising and Processing

   PEs advertise local <CPI, PPI> tuples in L1VPN LSAs containing L1VPN
   Info TLVs. Each PE MUST originate a separate 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 as per
   [RFC3630] and [RFC4203].  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 [RFC3630] and
   [RFC4203]. 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.

   L1VPN LSAs are of AS-scope (LS type is set to 11) and therefor are
   flooded to all PEs within the AS according to [2370BIS]. Every time a
   PE receives a new, removed or modified 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.


3.1. Discussion and Example

   The L1VPN auto-discovery mechanism described in this document does
   not prevent a PE from applying any local policy with respect to PIT
   management. For example, it should be possible to configure permanent
   (static) PIT entries, blocking of information carried in L1VPN LSAs
   that are advertised by some remote PEs from making it to the PITs.




Bryskin & Berger             Standards Track                    [Page 8]

Internet-Draft draft-ietf-l1vpn-ospf-auto-discovery-06.txt   May 13, 2008


   The reason why it is required that the value specified in the PE TE
   Address field of the L1VPN Info TLV matches a valid PE TE Router ID
   or numbered TE Link ID is to ensure that CEs attached to this PE can
   be resolved to the PE as it is known to the Traffic Engineering
   Database (TED) and hence TE paths toward the CEs across the Provider
   domain can be computed.

   Let us consider the example presented in Figure 2.


                            CE11               CE13
                              |                 |
                      CE22---PE1--------P------PE2
                              |         |
                             CE15      PE3
                                        |
                                       CE24

                    Figure 2: Single area configuration

   Let us assume that PE1 is connected to CE11 and CE15 in L1VPN1 and to
   CE22 in L1VPN2; PE2 is connected to CE13 in L1VPN1; PE3 is connected
   to CE24 in L1VPN2. In this configuration PE1 manages two PITs: PIT1
   for L1VPN1 and PIT2 for L1VPN2; PE2 manages only PIT1, and PE3
   manages only PIT2. PE1 originates three L1VPN LSAs, each containing a
   L1VPN Info TLV advertising links PE1-CE11, PE1-CE22 and PE1-CE15
   respectively. PE2 originates a single L1VPN LSA for link PE2-CE13 and
   PE3 originates a single L1VPN LSA for link PE3-CE24. In steady state
   the PIT1 on PE1 and PE3 will contain information on links PE1-CE11,
   PE1-CE15 and PE2-CE13; PIT2 on PE1 and PE2 will contain entries for
   links PE1-CE22 and PE3-CE24. Thus, all PEs will learn about all
   remote PE-CE links for all L1VPNs supported by PEs.

   Note that P in this configuration does not have links connecting it
   to any of L1VPNs. It neither originates L1VPN LSAs nor maintains any
   PITs. However, it does participate in the flooding of all of the
   L1VPN LSAs and hence maintains the LSAs in its LSDB. This is a cause
   for scalability concerns and could prove to be problematic in large
   networks.












Bryskin & Berger             Standards Track                    [Page 9]

Internet-Draft draft-ietf-l1vpn-ospf-auto-discovery-06.txt   May 13, 2008


4. Backward Compatibility

   Neither the TLV nor the LSA introduced in this document present any
   interoperability issues. Per [2370BIS], OSPF speakers that do not
   support the L1VPN auto-discovery application (Ps for example) just
   participate in the L1VPN LSAs flooding process but should ignore the
   LSAs contents.


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 [RFC2328] and
   [2370BIS].  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 experimental extension to OSPF, see [RFC2154],
   which supports the signing and authentication of LSAs.


6. IANA Considerations

   This document requests the assignment of an OSPF Opaque LSA type, see
   http://www.iana.org/assignments/ospf-opaque-types.  IANA is requested
   to make an assignment in the form:

       Value   Opaque Type                              Reference
      -------  -----------                              ---------
          TBA  L1VPN LSA                                [this document]

      A value of 4 is suggested for TBA.











Bryskin & Berger             Standards Track                   [Page 10]

Internet-Draft draft-ietf-l1vpn-ospf-auto-discovery-06.txt   May 13, 2008


7. Acknowledgment

   We would like to thank Adrian Farrel and Anton Smirnov for their
   useful comments.


8. References

8.1. Normative References

   [2370BIS] Berger, L., Bryskin, I., Zinin, A., "The OSPF Opaque LSA
             Option", work in progress, draft-ietf-ospf-rfc2370bis,
             May 8, 2008.

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

   [RFC2328] Moy, J., "OSPF Version 2 ", RFC 2328, April 1998.

   [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-fedyk-l1vpn-basic-mode, work in progress.


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.

   [L1VPN-BGP] Ould-Brahim H.,  Fedyk D., Rekhter, Y.,
               "BGP-based Auto-Discovery for L1VPNs",
               draft-ietf-l1vpn-bgp-auto-discovery, work in progress.








Bryskin & Berger             Standards Track                   [Page 11]

Internet-Draft draft-ietf-l1vpn-ospf-auto-discovery-06.txt   May 13, 2008


9. Authors' Addresses

   Igor Bryskin
   ADVA Optical Networking Inc
   7926 Jones Branch Drive
   Suite 615
   McLean, VA - 22102
   Email: ibryskin@advaoptical.com

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




Bryskin & Berger             Standards Track                   [Page 12]

Internet-Draft draft-ietf-l1vpn-ospf-auto-discovery-06.txt   May 13, 2008


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









































Bryskin & Berger             Standards Track                   [Page 13]
Generated on: Tue May 13 11:24:17 EDT 2008


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