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]
