One document matched: draft-ietf-ion-nhrp-vpn-00.txt

Internet Engineering Task Force                           Barbara A. Fox
INTERNET-DRAFT                                       Lucent Technologies
<draft-ietf-ion-nhrp-vpn-00.txt>                          Bernhard Petri
Expires September, 1999                                       Siemens AG






               NHRP Support for Virtual Private Networks


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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.

Abstract

   The NBMA Next Hop Resolution Protocol (NHRP) is used to determine the
   NBMA subnetwork addresses of the "NBMA next hop" towards a public
   internetworking layer address (see [1]).  This document describes the
   enhancements necessary to enable NHRP to perform the same function
   for private internetworking layer addresses available within the
   framework of a Virtual Private Network (VPN) service on a shared NBMA
   network.

1. Introduction

   NHRP is a public internetworking layer based resolution protocol.
   There is an implicit understanding in [1] that a control message



Fox, Petri                                             [Page 1] 




INTERNET-DRAFT                  NHRP VPN        Expires September 1999


   applies to the public address space.

   Service Providers of Virtual Private Network (VPN) services will
   offer VPN participants specific service level agreements (SLA) which
   may include, for example, dedicated routing functions and/or specific
   QoS levels.  A particularly important feature of a VPN service is the
   ability to use a private address space which may overlap with the
   address space of another VPN or the Public Internet.  Therefore, such
   an internetworking layer address only has meaning within the VPN in
   which it exists.  For this reason, it is necessary to identify the
   VPN in which a particular internetworking layer address has meaning,
   the "scope" of the internetworking layer address.

   As VPNs are deployed on shared networks, NHRP may be used to resolve
   a private VPN address to a shared NBMA network address.  In order to
   properly resolve a private VPN address, it is necessary for the NHRP
   device to be able to identify the VPN in which the address has
   meaning and determine resolution information based on that "scope".

2. Overview of NHRP VPN Indication

   When supporting NHRP for a VPN, it is necessary to specify to which
   VPN the NHRP message applies in order to comply with the VPN service
   level agreement applicable to that VPN.

   On some NBMA networks, it is possible to establish a VPN-specific
   control path between NHRP devices.  This is sufficient to identify
   the NHRP control packets as belonging to the "inherited" VPN.
   However, when that alternative is not used, the NHRP device must
   specify the VPN to which an NHRP control packet applies in the PDU.

   It is not useful to add a VPN extension to NHRP control messages
   because transit NHRP Servers are not required to process the
   extensions to an NHRP control message (see 5.3 in [1]).  NHRP Servers
   already deployed might resolve the control packet within the scope of
   the public internetworking layer address space instead of the private
   address space causing problems in routing.

   Instead, an LLC/SNAP header with a VPN indication (as specified in
   Section 8 of [2]) will be prepended to the NHRP control message.
   This solution allows the same VPN-specific LLC/SNAP header to be
   prepended to PDUs in both the control and data paths.

3. NHRP VPN Operation

   When an NHRP device forwards an NHRP control packet pertaining to a
   particular VPN, that VPN must be indicated either:




Fox, Petri                                             [Page 2] 




INTERNET-DRAFT                  NHRP VPN       Expires September 1999


     a) explicitly through use of the VPN-specific LLC/SNAP header or
     b) implictly through an indication in control path establishment.

   This applies to NHC-NHS, NHS-NHS, and NHS-NHC messages.

   For case a), the indication of the VPN-ID via a VPN-specific LLC/SNAP
   header is specified in [2].

   For case b), the method used to indicate the VPN-ID within control
   path establishment depends on the mechanisms available in the
   underlying network and is outside the scope of this draft.

   In transiting an NHRP Server, the VPN identification may be forwarded
   in a different format than was received, however, the same VPN ID
   must be indicated for the message.  For example, a PDU received with
   an LLC/SNAP header containing a VPN identifier MAY be forwarded on a
   control path which was established with an indication of the same VPN
   without the VPN-specific LLC/SNAP header.

   If a PDU with a VPN-specific LLC/SNAP header is received on a control
   path that was established with a VPN indication, the PDU may be
   dropped as specified in Section 8.3 of [2].  If it is not dropped,
   the VPN identifiers MUST match.  If the processed PDU indicates a
   different VPN, an NHRP Error Indication (see 5.2.7 of [1]) shall be
   returned to the sender with an Error Code 16 (VPN mismatch).

   When a VPN capable device receives an NHRP message without a VPN
   indication, the message applies to the public address space.  If a
   VPN capable device receives an NHRP message for a VPN that it does
   not support, that message MAY be silently discarded or an NHRP Error
   Indication (see 5.2.7 of [1]) MAY be returned to the sender with an
   Error Code 17 (VPN not supported).

4. NHRP Packet Formats

   VPN-specific NHRP control messages forwarded on a non VPN-specific
   control path MUST be prepended with the VPN-specific LLC-SNAP header
   as defined in Section 8 of [2].

   The following further Error Codes are defined in addition to those
   specified in section 5.2.7 of [1]):

      16 - VPN mismatch

        This error code is returned by a VPN-capable NHRP device, if it
        receives a PDU on the control path with a VPN-ID in the LLC/SNAP
        header different from the VPN-ID which had been specified for
        that control path at its establishment.



Fox, Petri                                             [Page 3] 




INTERNET-DRAFT                  NHRP VPN          Expires September 1999


      17 - VPN not supported

        This error code is returned by a VPN-capable NHRP device, if it
        receives an NHRP message for a VPN that it does not support.


References

[1] Luciani, J., Katz, D., Piscitello, D., Cole, B., and
    N. Doraswamy, "NMBA Next Hop Resolution Protocol (NHRP)", RFC
    2332, April 1998.

[2] Grossman, D. and Heinanen, J. "Multiprotocol Encapsulation over ATM
    Adaptation Layer 5", work in progress.




Author Information


   Barbara A. Fox
   Lucent Technologies
   300 Baker Ave, Suite 100
   Concord, MA  01742-2168
   phone: +1-978-287-2843
   email: barbarafox@lucent.com

   Bernhard Petri
   Siemens AG
   Hofmannstr. 51
   Munich, Germany, D-81359
   phone: +49 89 722-34578
   email: bernhard.petri@icn.siemens.de

















Fox, Petri                                             [Page 4]