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

Versions: 00 01

Network Working Group                                       T. Kuwahara
Internet Draft                                              J. Murayama
Expires: December 2001                                       N. Yoshida
                                                            M. Tanikawa
                                                        NTT Corporation
                                                          June 19, 2001

            Scalable Connectionless Tunneling Architecture
                         and Protocols for VPNs
                <draft-kuwahara-cl-tunneling-vpn-00.txt>


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

   This document defines a connectionless tunneling architecture that is
   applicable to provider provisioned virtual private networks (PPVPNs)
   and specifies protocols for implementing it.  This architecture is
   designed to facilitate scalable operation, load balancing, and high
   reliability.  A prominent feature of it is to provide VPN tunnels
   over a connectionless network.  Since a connectionless network can
   provide full mesh connectivity without a connection establishing
   procedure, the architecture enables scalable operation of a VPN more
   efficiently than connection-oriented tunneling technologies.







Kuwahara et al.          Expires December 2001                  [Page 1]


Internet Draft           CL Tunneling for VPNs                June, 2001


Table of Contents

   1. Introduction .................................................  3
   2. Connectionless Tunneling Architecture ........................  4
   3. Protocol Suite ...............................................  6
     3.1 Overview ..................................................  6
     3.2 Connectionless Tunneling Control Protocol .................  7
       3.2.1 Message Format ........................................  7
       3.2.2 Procedures ............................................  9
   4. Security Considerations ...................................... 11
   5. Acknowledgements ............................................. 11
   6. References ................................................... 11
   7. Authors' Addresses ........................................... 12

   Appendix A:
      Example Configuration Scheme for Core Network Address ........ 13
   Appendix B:
      ATM-based Protocol Suite ..................................... 14

   Full Copyright Statement ........................................ 27































Kuwahara et al.          Expires December 2001                  [Page 2]


Internet Draft           CL Tunneling for VPNs                June, 2001


1. Introduction

   This document defines a connectionless (CL) tunneling architecture
   that is applicable to provider provisioned virtual private networks
   (PPVPNs) [PPVPN-FR].  It also specifies protocols for implementing
   the CL tunneling architecture.  A prominent feature of this
   architecture is establishing VPN tunnels [PPVPN-FR] using
   connectivity provided by a connectionless Service Provider (SP)
   network (e.g., an IP routing network).  Here, such a VPN tunnel and a
   CL SP network [PPVPN-FR] are called a CL tunnel and a core network,
   respectively.  This architecture is designed to satisfy the following
   objectives:
    - scalable operation,
    - load balancing, and
    - high reliability.

   This architecture is based on the reference model for the layer 3
   network-based VPN (NBVPN) defined in [PPVPN-FR].  It assumes that an
   SP network consists of Provider Edge (PE) routers, which accommodate
   Customer Edge (CE) devices, and Provider (P) routers, which
   interconnect PEs but do not provide VPN-specific functionalities.  A
   PE router can support more than one VPN.  A VPN is supported by a VPN
   Forwarding Instance (VFI), which is implemented within a PE.

   One of the major issues of PPVPNs using a connection-oriented
   tunneling technology is the large number of connections, each of
   which provides an associated VPN tunnel, when the number of PEs
   and/or VPNs is increased.  To solve this issue and achieve scalable
   operation, this architecture deploys a core network in which full
   mesh connectivity is achieved without a connection establishment
   procedure, although appropriate updating of routing information is
   needed to maintain the connectivity of the core network.  By applying
   the hierarchical addressing configuration described in Appendix A to
   the core network, we further reduce the processing load needed to
   maintain the connectivity.

   For efficient use of network resources and reliable operation, load
   balancing and support for multiple routes between PEs are necessary.
   To satisfy these requirements, CL tunnels between VFIs need to be
   mapped to appropriate routes between PEs.  Thus, this architecture
   specifies a VFI addressing scheme that enables explicit routing in
   order to support these features.

   Note that the CL tunneling technology specified in this architecture
   also supports DiffServ [RFC2474], which is supported by other
   tunneling technologies.

   In this document, Section 2 defines the CL tunneling architecture,



Kuwahara et al.          Expires December 2001                  [Page 3]


Internet Draft           CL Tunneling for VPNs                June, 2001


   and section 3 specifies protocols applied to this architecture based
   on IPv6 [RFC2460].  In addition, Appendix A describes an example
   configuration for addressing used in CL networks enabling efficient
   operation of VPNs.  Appendix B specifies an ATM-based protocol suite
   that makes use of cell-based encapsulation to improve forwarding
   performance.

2. Connectionless Tunneling Architecture

   This section specifies a CL tunneling architecture that is applicable
   to PPVPNs.  In this architecture, the same names are used for those
   entities already defined in [PPVPN-FR].

   A network model is shown in Figure 2.1.  In this model, an access
   network connects a CE with a PE.  Note that this document does not
   specify any details of the access network.

              Access            SP Network            Access
              Network          (Core Network)         Network
          |<--------->|<-------------------------->|<--------->|

                     PE              P             PE
                +----------+      +-----+      +----------+
                |          |IP VPN|     |      |          |
      +-------------------------------------------------------------+
      |  +--+   |   +---+  |      |     |      |  +---+   |   +--+  |
      |  |CE|-------|VFI|<=======================>|   |-------|CE|  |
      |  +--+   |   +---+  |  CL  |     |      |  |   |   |   +--+  |
      |         |          |Tunnel|     |      |  |VFI|   |         |
      +-------------------------------------+  |  |   |   |   +--+  |
                |          |      |     |   |  |  |   |-------|CE|  |
      +-----------------------+   |     |   |  |  +---+   |   +--+  |
      |  +--+   |   +---+  |  |   |     |   +-----------------------+
      |  |CE|-------|   |  |  |   |     |      |          |
      |  +--+   |   |   |  |  +-------------------------------------+
      |         |   |VFI|  |      |     |  CL  |          |         |
      |  +--+   |   |   |  |      |     |Tunnel|  +---+   |   +--+  |
      |  |CE|-------|   |<=======================>|VFI|-------|CE|  |
      |  +--+   |   +---+  |      |     |      |  +---+   |   +--+  |
      +-------------------------------------------------------------+
                |          |      |     |IP VPN|          |
                +----------+      +-----+      +----------+

                        Figure 2.1 Network Model

   A VFI is created for each VPN in a PE to support VPN functionality
   specific to the associated VPN.  An access network provides point-
   to-point access connections between CEs and VFIs belonging to the



Kuwahara et al.          Expires December 2001                  [Page 4]


Internet Draft           CL Tunneling for VPNs                June, 2001


   same VPN.  A core network provides connectivity among VFIs belonging
   to a VPN.  An IP packet sent from a CE is received by a VFI and
   forwarded to an appropriate VFI via the core network, and then sent
   to a destination CE.  Each VFI searches its IP forwarding table using
   the destination IP address in the received IP packet as a key when it
   forwards an IP packet to the next hop PE/CE.  Here, an IP packet
   forwarded between CEs over a core network is called a tunneled IP
   packet.

   A protocol that supports the connectivity of core networks is called
   a core network protocol.  An address used by the core network
   protocol is called a core network address.  This core network address
   is assigned to a VFI in a PE.

   CL tunnels over a core network are implemented by associating each
   entry in the IP forwarding table with the core network address of an
   appropriate egress VFI.  Since the core network provides full mesh
   connectivity with no preceding connection establishing procedure, a
   tunneled IP packet (encapsulated in the core network protocol PDU)
   can be forwarded to the VFI by simply setting the core network
   address of an egress VFI in the core network protocol PDU.

   In this architecture, a CL tunnel between a pair of PEs is supported
   either by directly forwarding the core network protocol PDUs or by
   forwarding them through one or more P routers as intermediate nodes.
   Here, a PE (as well as a P router) searches its core forwarding table
   using the destination core network address as a key to find a P/PE
   router as the next hop.

   In this model, PEs process IP packets as follows:

   (1) Ingress PE
   When an IP packet is sent from a CE to a PE, the IP packet is
   delivered to the VFI that is associated with the access connection
   (and thus, associated with a specific VPN).  The VFI searches its IP
   forwarding table using the destination IP address as a key and
   resolves the core network address identifying the destination VFI.
   Then, the VFI searches its core forwarding table to determine the P
   or PE as the next hop by using the destination core network address
   as a key.  Then, the ingress PE encapsulates the IP packet into a
   core network protocol PDU, and forwards it toward the next hop
   (P/PE).

   (2) Egress PE
   When receiving a core network protocol PDU from a P router or an
   ingress PE, the VFI in an egress PE decapsulates the IP packet from
   the PDU, and determines the appropriate access connection by
   searching the IP forwarding table using the destination IP address as



Kuwahara et al.          Expires December 2001                  [Page 5]


Internet Draft           CL Tunneling for VPNs                June, 2001


   a key. Then, the egress PE forwards the IP packet toward the
   destination CE via the access connection.

   This architecture enables the use of both "full mesh" and "hub and
   spoke" (Figure 2.2) CL tunnel topologies.  In the latter, the PE used
   as the hub is called a Default Forwarder (DF) and the route from a PE
   to a DF is called the default route.  When a direct route between PEs
   is lightly loaded, it is possible to use the default route to support
   the traffic between these PEs and thus reduce the number of entries
   in the IP forwarding table within a VFI.

   To reduce the load on a DF, this architecture also supports dynamic
   creation of a cut-through CL tunnel (bypassing a DF) between two PEs.
   This feature is enabled by Connectionless Tunneling Control Protocol
   (CTCP) defined in Section 3.2.

          <=====>: CL tunnel for default route forwarding
          <----->: CL tunnel for cut through route forwarding

                           +------------+
        +----+             |     P      |             +----+
        | PE |<======================================>| DF |
        |    |<------------------+      |             |    |
        +----+             |     |      |             |    |
                           |     |      |             |    |
        +----+             |     |      |             |    |
        | PE |<------------------+      |             |    |
        |    |<======================================>|    |
        +----+             |            |             |    |
                           |            |             |    |
        +----+             |            |             |    |
        | PE |<======================================>|    |
        +----+             |            |             +----+
                           +------------+

                   Figure 2.2 Hub and Spoke Topology

3. Protocol Suite

   This section specifies the protocol suite to be applied to the
   architecture specified in Section 2.

3.1 Overview

   Figure 3.1 shows the protocol suite to be applied to the CL tunneling
   architecture.

   IPv6 [RFC2460] and ICMPv6 [RFC2463] are used for the core network



Kuwahara et al.          Expires December 2001                  [Page 6]


Internet Draft           CL Tunneling for VPNs                June, 2001


   protocol.  Here, a core network protocol PDU is constructed by
   encapsulating an IP packet received from a CE into an IPv6 packet
   format as specified in [RFC2473].  Quality-of-service (QoS) control
   in core networks conforms to Diffserv specifications for IPv6
   [RFC2474].

   The Connectionless Tunneling Control Protocol (CTCP) specified in
   Section 3.2 is used for controlling the cut-through packet
   forwarding.  This protocol is specified over UDP, while the port
   number of UDP for identifying CTCP is TBD.

                                {RFC 2463}
                                    |
                                    V
                    +----------+----------+----------+
  {Section 3.2}---> |   CTCP   |  ICMPv6  |    IP    |
                    +----------+          |          |
                    |   UDP    |          |          |
                    +----------+----------+----------+ <---{RFC 2473}
                    |              IPv6              | <---{RFC 2460}
                    +--------------------------------+

                 Figure 3.1 IPv6-based Protocol Suite
                            for the CL Tunneling Architecture

3.2 Connectionless Tunneling Control Protocol

   The Connectionless Tunneling Control Protocol (CTCP) is a protocol
   for controlling cut-through packet forwarding of tunneled IP packets
   within a VPN supported by core networks.

3.2.1 Message Format

   Every CTCP message is preceded by a UDP header.  CTCP messages have
   the following general format:
















Kuwahara et al.          Expires December 2001                  [Page 7]


Internet Draft           CL Tunneling for VPNs                June, 2001


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     TYPE      |      CODE     |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Operation ID          | Address Type  | Prefix Length |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                          Target Address                       +
   |                                                               |
   ~                                                               ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                      Resolved IPv6 Address                    +
   |                            (128 bits)                         |
   ~                                                               ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                                                               ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Operation ID          | Address Type  | Prefix Length |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                          Target Address                       +
   |                                                               |
   ~                                                               ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                       Resolved IPv6 Address                   +
   |                             (128 bits)                        |
   ~                                                               ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:            8-bit unsigned integer.  The type field
                    indicates the type of message.  Its value
                    determines the format of the remaining data.
   Code:            8-bit unsigned integer.  The code field depends
                    on the message type.  It is used to create an
                    additional level of message granularity.
                    The following sets of TYPE/CODE are defined
                         1/1  Tunnel Redirection Notification
                         1/2  Tunnel Purge Notification




Kuwahara et al.          Expires December 2001                  [Page 8]


Internet Draft           CL Tunneling for VPNs                June, 2001


   Operation ID:    Identifies operations in the message.
                    16-bit unsigned integer.
   Address Type:    Protocol number in [RFC1700], which indicates
                    the type of the target address.
                    8-bit unsigned integer.
   Prefix Length:   Length of the target address prefix.
                    8-bit unsigned integer.
   Target Address:  Destination IP address for the cut-through
                    tunnel to be used/cancelled.
   Resolved IPv6 Address:
                    IPv6 address of the egress VFI to which the
                    cut-through tunnel shall be used/cancelled.
                    128-bit unsigned integer.
   Descriptions:
   A Tunnel Redirection Notification message (Type=1, Code=1) is used by
   a VFI to request an ingress VFI that tunneled IP packets with the
   indicated address prefix be forwarded via a new cut-through tunnel
   indicated in the message.

   A Tunnel Purge Notification message (Type=1, Code=2) is used by a VFI
   to request the ingress VFI to discontinue the forwarding of tunneled
   IP packets through the cut-through tunnel indicated in the message.

3.2.2 Procedures

   This section specifies the Tunnel Redirection and Tunnel Purge
   procedures.  These are unconfirmed procedures, so their protocol
   instances can be implemented as stateless processes, because they do
   not create any response messages.

   In a core network with "hub and spoke" topology, a tunneled IP packet
   is forwarded from an ingress PE to a DF.  Then the DF forwards the
   received tunneled IP packet to the egress PE identified by the
   destination address of the tunneled IP packet.  At the same time, the
   DF asks the ingress PE for redirection via a cut-through CL tunnel by
   sending a Tunnel Redirection Notification message (Type=1, Code=1).

   In this message, the Target Address field contains the destination IP
   address of the tunneled IP packet that has triggered the redirection
   control.  Prefix Length fields and Resolved IPv6 Address fields
   contain prefix length of the taget address and the PE address
   obtained by table searching, respectively.

   When an ingress VFI receives a Tunnel Redirection Notification
   message, it adds the notified entry information in its IP forwarding
   table as a tunnel redirection entry.  This is because tunnel
   redirection entries may be removed by the tunnel purge procedure.  As
   a result, succeeding tunneled IP packets to the same destination are



Kuwahara et al.          Expires December 2001                  [Page 9]


Internet Draft           CL Tunneling for VPNs                June, 2001


   forwarded through the cut-through CL tunnel.

       (2) Tunnel Redirection
          Notification       +------------+
          +------------------|Intermediate|
          |   +------------->|  DF (VFI)  |------------+
          |   |  (1) Default +------------+(1) Default |
          |   |  Forwarding                 Forwarding |
          |   |                                        |
          V   |           <Core Network>               V
      +-----------+                              +-----------+
      |  Ingress  | (3) Cut-Through Forwarding   |  Egress   |
      |  PE (VFI) |----------------------------->|  PE (VFI) |
      +-----------+                              +-----------+

      Figure 3.2 Tunnel Redirection Control by the Intermediate
                 Default Forwarder (DF)

   When a VFI in a PE receives a tunneled IP packet from a cut-through
   CL tunnel, it searches the IP forwarding table.  If the destination
   address does not match any entry in the table, the VFI discards the
   IP packet and sends the ingress VFI a Tunnel Purge Notification
   message (Type=1, Code=2) to stop the redirection using the cut-
   through CL tunnel.  This message contains the Target IP Address and
   Resolved IPv6 Address but no Prefix Length.

   When an ingress VFI receives a Tunnel Purge Notification message, it
   searches the IP forwarding table using the notified IP address as a
   key.  And if the IP address matches a tunnel redirection entry, the
   VFI removes the entry.  Thus, IP packets toward the same destination
   are forwarded to the default route to a DF.

                       +------------+
                       |Intermediate|
        +------------->|  DF (VFI)  |--------------------------+
        | (3) Default  +------------+  (3) Default Forwarding  |
        |  Forwarding                                          |
        |                                                      |
        |                   <Core Network>                     |
        |                                                      V
  +---------+ (1) Cut-Through Forwarding  +-------------+ +-----------+
  |         |---------------------------->|Inappropriate| |Appropriate|
  | Ingress |                             |   Egress    | |  Egress   |
  | PE (VFI)|<----------------------------|   PE (VFI)  | |  PE (VFI) |
  +---------+(2) Tunnel Purge Notification+-------------+ +-----------+

        Figure 3.3 Tunnel Purge Control by the Egress Edge Node




Kuwahara et al.          Expires December 2001                 [Page 10]


Internet Draft           CL Tunneling for VPNs                June, 2001


4. Security Considerations

   The level of security provided by this CL tunneling architecture is
   identical to that provided by the tunneling technologies using layer
   3 connectivity, since the core network providing these tunnels is
   operated not by users but by an SP in a manner invisible to users.

5. Acknowledgements

   This architecture and protocol specifications are outputs of GMN-CL
   (Global Megamedia Networks based on Connectionless Technologies)
   project in NTT.  The authors would like to acknowledge
    - O. Tabata and T. Iwase (NEC Corporation),
    - M. Inami and E. Takahashi (Fujitsu Limited),
    - H. Takenoshita and Y. Araki (Oki Electric Industry Company),
    - K. Kitami (NTT Corporation)
   for discussions and comments on the specification and
   implementations.

6. References

   [PPVPN-FR]  Callon, R., Suzuki, M., et al., "A Framework for
               Provider Provisioned Virtual Private Networks,"
               Internet-draft <draft-ietf-ppvpn-framework-00.txt>,
               February 2001.

   [RFC2474]   Nichols, K., Blake, S., Baker, F., and Black, D.,
               "Definition of the Differentiated Services Field
               (DS Field) in the IPv4 and IPv6 Headers," RFC 2474,
               December 1988.

   [RFC2460]   Deering, S., and Hinden, R., "Internet Protocol,
               Version 6 (IPv6) Specification," RFC 2460,
               December 1998.

   [RFC2463]   Conta, A., and Deering, S., "Internet Control Message
               Protocol (ICMPv6) for the Internet Protocol Version 6
               (IPv6) Specification," RFC 2463, December 1988.

   [RFC2473]   Conta, A., et al., "Generic Packet Tunneling in IPv6
               Specification," RFC 2473, December 1988.

   [RFC1700]   Reynolds, J., and Postel, J., "Assigned Numbers",
               RFC 1700, October 1994.  See also:
               http://www.iana.org/numbers.html

   [RFC2373]   Hinden, R., and Deering, S., "IP Version 6 Addressing
               Architecture," RFC 2373, July 1998.



Kuwahara et al.          Expires December 2001                 [Page 11]


Internet Draft           CL Tunneling for VPNs                June, 2001


   [I.361]     "B-ISDN ATM Layer Specification," I.361 ITU-T
               Recommendation, February 1999.

   [I.363.5]   "B-ISDN ATM Adaptation Layer (AAL) Type 5
               Specification," I.363.5 ITU-T Recommendation,
               August 1996.

   [RFC2684]   Grossman, D., and Heinanen, J., "Multiprotocol
               Encapsulation over ATM Adaptation Layer 5," RFC 2684,
               September 1999.

   [E.164]     "The International Public Telecommunication Numbering
               Plan," E.164 ITU-T Recommendation, May 1997.

7. Authors' Addresses

   Takeshi Kuwahara
   NTT Corporation,
   3-9-11, Midori-cho,
   Musashino-shi, Tokyo 180-8585, Japan
   Email: kuwahara.takeshi@lab.ntt.co.jp

   Junichi Murayama
   NTT Corporation,
   3-9-11, Midori-cho,
   Musashino-shi, Tokyo 180-8585, Japan
   Email: murayama.junichi@lab.ntt.co.jp

   Norishige Yoshida
   NTT Corporation,
   3-9-11, Midori-cho,
   Musashino-shi, Tokyo 180-8585, Japan
   Email: yoshida.norishige@lab.ntt.co.jp

   Masaki Tanikawa
   NTT Corporation,
   3-9-11, Midori-cho,
   Musashino-shi, Tokyo 180-8585, Japan
   Email: tanikawa.masaki@lab.ntt.co.jp












Kuwahara et al.          Expires December 2001                 [Page 12]


Internet Draft           CL Tunneling for VPNs                June, 2001


Appendix A:  Example Configuration Scheme for Core Network Address

   This appendix shows an example configuration scheme for the core
   network address to achieve efficient operation of the core network
   protocol specified in Section 3 of this document.

   In a core network, an IPv6 address is assigned to a VFI as a core
   network address. As multiple VFIs are generally created in a PE/DF,
   load balancing among VPNs is possible in core networks.  If SLA ID
   and INTERFACE ID in the Aggregatable Global Unicast Addresses
   [RFC2373] are configured hierarchically, the following information
   can be directly extracted from the IPv6 Addresses used in a core
   network.
    - Area identification (identifies an area accommodating the
      addressed VFI within a core network identified by TLA and NLA
      of the IPv6 address),
    - PE/DF identification (identifies a PE/DE supporting the addressed
      VFI in the indicated area), and
    - VPN identification (identifies the VPN to which the addressed VFI
      is associated).

   The address configuration scheme described above enables:
    - route aggregation by using AREA IDs for each area,
    - load balancing among routes toward a certain AREA, by assigning
      multiple AREA IDs to the AREA,
    - load balancing among routes toward a certain PE/DF, by assigning
      multiple PE/DF IDs to the PE/DF supporting the addressed VFI,
    - efficient VPN operation by using core addresses including explicit
      VPN identification as well as explicit Area and PE/DF
      identifications.

   The same hierarchical address configuration scheme can also be
   defined to achieve efficient operation when the Site-Local Address of
   Local-Use Unicast Address [RFC2373] is used for VFI addresses in the
   core network.
















Kuwahara et al.          Expires December 2001                 [Page 13]


Internet Draft           CL Tunneling for VPNs                June, 2001


Appendix B:  ATM-based Protocol Suite

B.1 Introduction

   This appendix specifies an ATM-based protocol suite applicable to the
   CL tunneling architecture defined in this document. The core network
   protocol specified here (called the ATM-based core network protocol)
   is an essential part of the protocol suite. The ATM-based core
   network protocol is designed to satisfy the addressing requirements
   described in Appendix A and is also designed to achieve efficient
   encapsulation/decapsulation of core network protocol PDUs in PEs when
   both access networks and the core network are constructed on the
   basis of ATM.

B.2 Overview

   Figure B.1 shows the protocol suite designed for efficient operation
   in the ATM environment applicable to the CL tunneling architecture as
   specified in this document.  Section B.3 shows protocol stacks of the
   ATM-based protocol suite described in this appendix.  Section B.4
   describes the usage of the ATM protocol in the protocol suite.
   Section B.5 specifies the structure of an AAL5-CPCS PDU encapsulating
   a core network protocol PDU.  The ATM-based core protocol is
   specified in section B.6 and used for CL tunneling without a
   tunneling establishment procedure over ATM networks.  Section B.7
   describes scheme for encapsulating/decapsulating an IP packet from a
   user as a core network protocol PDU defined in Section B.5.  To
   control the core network applying the ATM-based core protocol, the
   Core Control Message Protocol (CCMP) is used; it is specified in
   section B.8.  CCMP is also used to control the tunnel configuration.

                {Section B.8}
                  |       |
                  V       V
        +-------------+-------------+-------------+
        |CCMP for     |CCMP for     |     IP      |
        |tunnel       |core network |             |
        |configuration|control      |             |
        +-------------+-------------+-------------|<--{Section B.7}
        |     ATM-based core network protocol     |<--{Section B.6}
        +-----------------------------------------+<--{Section B.5}
        |                   ATM                   |<--{Section B.4}
        +-----------------------------------------+

 Figure B.1 ATM-based Protocol Suite for the CL Tunneling Architecture






Kuwahara et al.          Expires December 2001                 [Page 14]


Internet Draft           CL Tunneling for VPNs                June, 2001


B.3 Protocol Stacks

B.3.1 Overview

   This section shows the protocol stacks of the ATM-based core network
   protocol described in this appendix.  Here, the forwarding plane
   corresponds to core network protocol PDU forwarding functions between
   PEs/DFs via P routers.  The core network control plane and the tunnel
   configuration plane correspond to the functions of CCMP described in
   Section B.8.

B.3.2 Forwarding Plane

   +---------+                                             +---------+
   |   IP    |                                             |   IP    |
   +----+----+                                             +----+----+
   |SNAP|SNAP|                                             |SNAP|SNAP|
   +----+----+                                             +----+----+
   |LLC |LLC |                                             |LLC |LLC |
   +----+----+                 +---------+                 +----+----+
   |    |CORE|<--------------->|  CORE   |<--------------->|CORE|    |
   +    +----+                 +----+----+                 +----+    +
   |    |SNAP|<--------------->|SNAP|SNAP|<--------------->|SNAP|    |
   +AAL5+----+                 +----+----+                 +----+AAL5+
   |    |LLC |<--------------->|LLC |LLC |<--------------->|LLC |    |
   +    +----+                 +----+----+                 +----+    +
   |    |AAL5|<--------------->|AAL5|AAL5|<--------------->|AAL5|    |
   +----+----+    +---+---+    +----+----+    +---+---+    +----+----+
   |ATM |ATM |<-->|ATM|ATM|<-->|ATM |ATM |<-->|ATM|ATM|<-->|ATM |ATM |
   +----+----+    +---+---+    +----+----+    +---+---+    +----+----+
   |PHY |PHY |<-->|PHY|PHY|<-->|PHY |PHY |<-->|PHY|PHY|<-->|PHY |PHY |
   +----+----+    +---+---+    +----+----+    +---+---+    +----+----+
      PE/DF        ATM Node      P router      ATM Node       PE/DF

           Figure B.2 Protocol Stack of the Forwarding Plane
















Kuwahara et al.          Expires December 2001                 [Page 15]


Internet Draft           CL Tunneling for VPNs                June, 2001


B.3.3 Core Network Control Plane

    +----+                                                     +----+
    |CCMP|<--------------------------------------------------->|CCMP|
    +----+                     +---------+                     +----+
    |CORE|<------------------->|  CORE   |<------------------->|CORE|
    +----+                     +----+----+                     +----+
    |SNAP|<------------------->|SNAP|SNAP|<------------------->|SNAP|
    +----+                     +----+----+                     +----+
    |LLC |<------------------->|LLC |LLC |<------------------->|LLC |
    +----+                     +----+----+                     +----+
    |AAL5|<------------------->|AAL5|AAL5|<------------------->|AAL5|
    +----+     +----+----+     +----+----+     +----+----+     +----+
    |ATM |<--->|ATM |ATM |<--->|ATM |ATM |<--->|ATM |ATM |<--->|ATM |
    +----+     +----+----+     +----+----+     +----+----+     +----+
    |PHY |<--->|PHY |PHY |<--->|PHY |PHY |<--->|PHY |PHY |<--->|PHY |
    +----+     +----+----+     +----+----+     +----+----+     +----+
   P or PE/DF    ATM Node       P Router       ATM Node     P or PE/DF

      Figure B.3 Protocol Stack of the Core Network Control Plane

B.3.4 Tunneling Configuration Plane

    +----+                                                     +----+
    |CCMP|                                                     |CCMP|
    +----+                     +---------+                     +----+
    |CORE|<------------------->|  CORE   |<------------------->|CORE|
    +----+                     +----+----+                     +----+
    |SNAP|<------------------->|SNAP|SNAP|<------------------->|SNAP|
    +----+                     +----+----+                     +----+
    |LLC |<------------------->|LLC |LLC |<------------------->|LLC |
    +----+                     +----+----+                     +----+
    |AAL5|<------------------->|AAL5|AAL5|<------------------->|AAL5|
    +----+     +----+----+     +----+----+     +----+----+     +----+
    |ATM |<--->|ATM |ATM |<--->|ATM |ATM |<--->|ATM |ATM |<--->|ATM |
    +----+     +----+----+     +----+----+     +----+----+     +----+
    |PHY |<--->|PHY |PHY |<--->|PHY |PHY |<--->|PHY |PHY |<--->|PHY |
    +----+     +----+----+     +----+----+     +----+----+     +----+
     PE/DF       ATM Node       P Router        ATM Node        PE/DF

          Figure B.4 Protocol Stack of the CL Tunneling Plane

B.4 ATM Protocol

   The ATM layer complies with ITU-T recommendation [I.361].  A VP is
   used to interconnect nodes (i.e., PE, DF, P) in a core network.

   The AAL layer complies with ITU-T recommendation of AAL5



Kuwahara et al.          Expires December 2001                 [Page 16]


Internet Draft           CL Tunneling for VPNs                June, 2001


   specification [I.363.5].  The AAL5 message mode shall be used.

B.5 AAL5-CPCS PDU for ATM-based Core Network Protocol PDU

   The ATM-based core network protocol PDU is encapsulated as an AAL5-
   CPCS PDU based on the "LLC Encapsulation for Routed Protocols" format
   defined in [RFC2684] using the LLC/SNAP header.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      DSAP     |      SSAP     |      Ctrl     |  OUI (Upper)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           OUI (Lower)         |           EtherType           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   ~                  Core Network Protocol PDU                    ~
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                              PAD                              ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      UU       |      CPI      |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              CRC                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    DSAP:              0xAA (Destination Service Access Point defined
                       in IEEE802.2 LLC header).
    SSAP:              0xAA (Source Service Access Point defined in
                       IEEE802.2 LLC header).
    Ctrl:              0x03 (SNAP identifier).
    OUI:               0x00-00-00.
    EtherType:         TBD.
    Core Network Protocol PDU:
                       Up to (2^16)-9 octets, the maximum length of
                       the Core Network Protocol PDU is 65527 octets.
    PAD:               From 0 to 47 octets.
    UU:                Should be 0x00.
    CPI:               Should be 0x00.
    Length:            This field shows the byte length of the
                       AAL5-CPCS PDU payload.  The value of 0x00 may
                       be used as an abort signal.



Kuwahara et al.          Expires December 2001                 [Page 17]


Internet Draft           CL Tunneling for VPNs                June, 2001


    CRC:               A CRC 32 is calculated for the entire AAL5-CPCS
                       PDU except for the CRC field itself.

   B.6 ATM-based Core Network Protocol

   B.6.1 ATM-based Core Network Protocol Header Format

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version| Traffic Class |              Reserved                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Reserved           |     HLSI      |   Hop Limit   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                 Source Core Network Address                   +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +               Destination Core Network Address                +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Version:        4-bit ATM-based core network protocol version
                    number.  The current version number is 1.
    Traffic Class:  8-bit unsigned integer.
                    This field is divided as follows in the core
                    network protocol:
                    +--+--+--+--+--+--+--+--+
                    | Priority  | Reserved  |
                    +--+--+--+--+--+--+--+--+
                    Priority: 4-bit unsigned integer.  This indicates
                              the priority of the core network
                              protocol PDU.  The values listed below
                              are used for priority identification:
                                0(0000B)  prio-0 PDU (lowest)
                                8(1000B)  prio-8 PDU
                               10(1010B)  prio-10 PDU
                               12(1100B)  prio-12 PDU (highest)
                               Others     unassigned



Kuwahara et al.          Expires December 2001                 [Page 18]


Internet Draft           CL Tunneling for VPNs                June, 2001


                    Reserved:  It must be encoded as all '0'.
    HLSI:           8-bit Higher Layer Service Identifier that
                    identifies the higher-layer protocols and
                    services carried by the core network protocol:
                        1   IPv4 service
                       16   CCMP core network control service
                       17   CCMP tunneling configuration service
                       Other values are reserved for future use.
    Hop Limit:      8-bit unsigned integer.
    Source Core Network Address:
                    128 bits.  See Section B.6.2 for the internal
                    structure.
    Destination Core Network Address:
                    128 bits.  See Section B.6.2 for the internal
                    structure.
    Reserved:       It must be encoded as all '0'.

    The maximum PDU length of the core network protocol is 65527 octets.

B.6.2 Structure of Source/Destination Core Network Address

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                           PE/DF ID                            +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                            VPN ID                             +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      PE/DF ID:     64 bits, identifying source/destination PE/DF.
                    See Section B.6.3 for the internal structure.
      VPN ID:       64 bits.
                    See Section B.6.4 for the internal structure.














Kuwahara et al.          Expires December 2001                 [Page 19]


Internet Draft           CL Tunneling for VPNs                June, 2001


B.6.3 Structure of PE/DF ID

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | FP  |        Reserved         |       PC      |       CC      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |        Area       |      PE/DF Group ID       | PE/DF ID  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       FP:       3-bit unsigned integer.
                 Format Prefix, encoded as 001B.
       Reserved  Encoded as all '0'.
       PC:       8-bit unsigned integer.
                 Provider Code - identifying the serving provider.
       CC:       10-bit unsigned integer.
                 Country Code - identifying the country where the
                 indicated area is located.  Its value is as specified
                 in [E.164] and encoded in binary.
       Area:     10-bit unsigned integer.
                 Area number - identifying an area in the indicated
                 country.
       PE/DF Group ID:
                 14-bit unsigned integer.
                 Identifying a physical node supporting a group of
                 PE/DF in the ATM-based core network.
       PE/DF ID: 6-bit unsigned integer.
                 PE/DF identifier in an identified PE/DF group.

   Note that a "PE/DF group" represents a physical node that terminates
   ATM connections of a core network and access networks.  It supports
   one or more PEs and DFs and the core network protocol based
   forwarding function to distribute core network protocol PDUs among
   accommodated PEs/DFs.

B.6.4 Structure of VPN ID

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Reserved   |                  VPN Number                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Reserved                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      VPN Number:   24-bit unsigned integer identifying the VPN.
      Reserved:     It must be encoded as all '0'.




Kuwahara et al.          Expires December 2001                 [Page 20]


Internet Draft           CL Tunneling for VPNs                June, 2001


B.7 Encapsulation Scheme for IP Packet from User

   This section describes how to encapsulate/decapsulate an IP packet
   over AAL5 from a user as an ATM-based core network protocol PDU
   defined in Section B.5.  The encapsulation/decapsulation scheme is
   designed to improve forwarding performance.

   The ingress PE can perform core network protocol PDU encapsulation on
   a cell-by-cell basis.  For this, the first cell of the core network
   protocol PDU is used to hold the core network protocol header.  The
   cell-divided IP packet received from an access connection conforms to
   the "LLC Encapsulation for Routed Protocols" format with the LLC/SNAP
   header defined in [RFC2684] and it is directly mapped to the
   following cells of the core network protocol PDU.  Consequently, the
   IP PDU is still encapsulated with the LLC/SNAP header even in the
   core network protocol PDU as shown in Figure B.2.  The core network
   protocol header is also encapsulated with the other LLC/SNAP header.
   The encapsulation scheme is shown in Figure B.5.  Here, the payload
   of last cell is modified because the AAL5-PDU trailer part should be
   reconfigured for the core network protocol PDU.  The egress PE
   decapsulates it by simply removing the first cell containing the core
   network protocol header and modifying the AAL5-PDU trailer part in
   the payload of the last cell.

                   |<- AAL5-CPCS PDU received from access network ->|
                   |                                                |
                   +-+-------+  +-+-------+  +-+-------+  +-+-------+
                   | | IPv4  |  | |       |  | |       |  | |       |
                   +-+-------+  +-+-------+  +-+-------+  +-+-------+
                   |First cell  |   cell  |  |   cell  |  |Last cell|
                   |         |  |         |  |         |  |         |
                   |         |  |         |  |         |  |         |
      +-+-------+  +-+-------+  +-+-------+  +-+-------+  +-+-------+
   <--| | core  |  | | IPv4  |  | |       |  | |       |  | |       |
      +-+-------+  +-+-------+  +-+-------+  +-+-------+  +-+-------+
      |Core cell       cell         cell         cell      Last cell|
      |                                                             |
      |<---------- AAL5-CPCS PDU sent to core network ------------->|

                     Figure B.5 Core Encapsulation

B.8 Core Control Message Protocol

   The Core Control Message Protocol (CCMP) specified here supports core
   network control and tunnel configuration.






Kuwahara et al.          Expires December 2001                 [Page 21]


Internet Draft           CL Tunneling for VPNs                June, 2001


B.8.1 Common Message Format

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     TYPE      |      CODE     |          Reserved             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                         Message Body                          +
   |                                                               |

    TYPE:           CCMP message identifier.
    CODE:           The value allocation method depends on the message
                    type. It is used to create an additional level of
                    message granularity.
    Reserved:       It must be encoded as all '0' by the sender, and
                    ignored by the receiver.
    Message Body:   The main body of the message.

   The assigned values of TYPE and CODE are listed in Table B.1.

                      Table B.1 CCMP Message Classes

     +---------------++----------------------------------+----+----+
     | Message Class || Message Contents                 |TYPE|CODE|
     +===============++==================================+====+====+
     | Core Network  || ECHO Request                     |   0|   0|
     | Control       || ECHO Reply                       |   1|   0|
     |               || Hop Limit Exceeded               |  16|   0|
     +---------------++----------------------------------+----+----+
     | Tunneling     || Tunnel Redirection Notification  |  32|   0|
     | Configuration || Tunnel Purge Notification        |  33|   0|
     +---------------++----------------------------------+----+----+

B.8.2 ECHO Request

   This message is transmitted to test the reachability to a destination
   and quality in the core layer.  Every node must be able to send and
   receive an ECHO Request message.
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     TYPE      |      CODE     |           Reserved            |4
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Identifier          |          Sequence Number      |8
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Data ......                                          |12
   +-+-+-+-+-+-+-+-+-+-



Kuwahara et al.          Expires December 2001                 [Page 22]


Internet Draft           CL Tunneling for VPNs                June, 2001


       TYPE:         8-bit unsigned integer  The ECHO request message
                     type.  It must be set to 0.
       CODE:         8-bit unsigned integer.  It must be set to 0.
       Identifier:   8-bit unsigned integer.  An identifier to match
                     the ECHO request with the ECHO reply.  It may be
                     used by higher-layer applications.
       Sequence Number:
                     16-bit unsigned integer.  A sequence number may
                     be used by higher-layer applications to match the
                     ECHO request with the ECHO reply.
       Data:         Zero or more bytes of arbitrary data.
       Reserved:     It must be encoded as all '0' by the sender, and
                     ignored by the receiver.

B.8.3 ECHO Reply

   This message is transmitted to confirm the reachability to a
   destination and quality in the core layer.  Every node must send an
   ECHO Reply message whenever it receives an ECHO Request message.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     TYPE      |      CODE     |           Reserved            |4
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Identifier          |          Sequence Number      |8
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Data ......                                          |12
   +-+-+-+-+-+-+-+-+-+-

       TYPE:             8-bit unsigned integer.
                         Echo reply message type. It must be set
                         to 1.
       CODE:             8-bit unsigned integer  It must be set
                         to 0.
       Identifier:       16-bit unsigned integer.  The identifier
                         extracted from the invoking ECHO Request
                         message.
       Sequence Number:  16-bit unsigned integer.  The sequence
                         number extracted from the invoking ECHO
                         Request message.
       Data:             The data extracted from the invoking ECHO
                         Request message.
       Reserved:         It must be encoded as all '0' by the sender,
                         and ignored by the receiver.






Kuwahara et al.          Expires December 2001                 [Page 23]


Internet Draft           CL Tunneling for VPNs                June, 2001


B.8.4 Hop Limit Exceeded

   This message is sent to the ingress PE when Hop Limit is exceeded.
   The message format 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     TYPE      |      CODE     |           Reserved            |4
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Reserved                          |8
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Data ......                                          |12
   +-+-+-+-+-+-+-+-+-+-

       TYPE:      Time Exceeded message type.  It must be set
                  to 16.
       CODE:      It must be set to 0.
       Data:      As much of the invoking packet as will fit without
                  the CCMP packet exceeding the minimum MTU of the
                  core network protocol.
       Reserved:  It must be encoded as all '0' by the sender, and
                  ignored by the receiver.

B.8.5 Tunnel Redirection Notification

   A DF sends a Tunnel Redirection Notification message to the ingress
   PE for redirection.  The message format is as follows:























Kuwahara et al.          Expires December 2001                 [Page 24]


Internet Draft           CL Tunneling for VPNs                June, 2001


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     TYPE      |     CODE      |          Reserved             |4
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Address Type  | Prefix Length |          Reserved             |8
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |12
   +                                                               +
   |                                                               |16
   +                         Target Address                        +
   |                                                               |20
   +                                                               +
   |                                                               |24
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |28
   +                                                               +
   |                 Resolved Core Network Address                 |32
   +                                                               +
   |                                                               |36
   +                                                               +
   |                                                               |40
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       TYPE:             8-bit unsigned integer.  The Tunnel
                         Redirection Notification message type.
                         It must be set to 32.
                         See Table B.1 for the allocation of values.
       CODE:             8-bit unsigned integer.  The Tunnel
                         Redirection Notification message class.
                         See Table B.1 for the allocation of values.
       Address Type:     8-bit unsigned integer.  It identifies the
                         address type of the target address:
                            IPv4  2
                            Other values are reserved.
       Prefix Length:    8-bit unsigned integer.  This part represents
                         the length of the prefix in the target address
                         in bits.
       Reserved:         It must be encoded as all '0' by the sender,
                         and ignored by the receiver.
       Target Address:   128-bit unsigned integer.  The target address
                         for which redirection is requested to be
                         initiated.
       Resolved Core Network Address:
                         128-bit unsigned integer.  The core network
                         address of the appropriate egress VFI.

B.8.6 Tunnel Purge Notification



Kuwahara et al.          Expires December 2001                 [Page 25]


Internet Draft           CL Tunneling for VPNs                June, 2001


   The egress PE sends a Tunnel Purge Notification message to the
   ingress PE to cancel redirection.  The message format 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     TYPE      |      CODE     |            Reserved           |4
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Address Type  | Prefix Length |            Reserved           |8
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |12
   +                                                               +
   |                                                               |16
   +                         Target Address                        +
   |                                                               |20
   +                                                               +
   |                                                               |24
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |28
   +                                                               +
   |                Resolved Core Network Address                  |32
   +                                                               +
   |                                                               |36
   +                                                               +
   |                                                               |40
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       TYPE:            8-bit unsigned integer.  The Tunnel Purge
                        Notification message type.  It must be set to
                        33.  See Table B.1 for the allocation of values.
       CODE:            8-bit unsigned integer.  The Tunnel Purge
                        Notification message class.  See Table B.1
                        for the allocation of values.
       Address Type:    8-bit unsigned integer.  It identifies the
                        address type of the target address:
                             IPv4  2
                             Other values are reserved.
       Prefix Length:   8-bit unsigned integer.  It must be encoded
                        as all '0' by the sender, and ignored by the
                        receiver.
       Reserved:        It must be encoded as all '0' by the sender,
                        and ignored by the receiver.
       Target Address:  128-bit unsigned integer.  The target address
                        for which redirection is requested to be
                        cancelled .
       Resolved Core Network Address:
                        128-bit unsigned integer.  The core network
                        address of the egress VFI.



Kuwahara et al.          Expires December 2001                 [Page 26]


Internet Draft           CL Tunneling for VPNs                June, 2001


Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.
























Kuwahara et al.          Expires December 2001                 [Page 27]


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