Network Working Group T. Kuwahara
Internet Draft J. Murayama
Expires: July 2003 M. Tanikawa
M. Suzuki
NTT Corporation
January 24, 2003
Scalable Connectionless Tunneling Architecture
and Protocols for VPNs
<draft-kuwahara-cl-tunneling-vpn-01.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 describes a connectionless tunneling architecture that
is applicable to layer 3 PE-based virtual private networks and
specifies protocols for implementing it. This tunneling architecture
is designed to facilitate scalability and 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 establishment procedure, the
architecture enables scalable operation of a VPN more efficiently
than connection-oriented tunneling technologies.
Kuwahara et al. Expires July 2003 [Page 1]
Internet Draft draft-kuwahara-cl-tunneling-vpn-01.txt January 2003
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 (CTCP)........... 7
3.2.1 Message Format ........................................ 7
3.2.2 Procedures ............................................ 9
3.2.3 Implementation Guidelines ............................. 11
4. Security Considerations ...................................... 13
5. Acknowledgements ............................................. 13
6. Normative References ......................................... 13
7. Informative References ....................................... 14
8. Authors' Addresses ........................................... 14
Appendix A:
Example Configuration Scheme for Core Network Address ........ 16
Appendix B:
Example Configuration for the Hub and Spoke Topology
with Multiple Hubs ........................................... 17
Appendix C:
ATM-based Protocol Suite ..................................... 19
Full Copyright Statement ........................................ 32
Kuwahara et al. Expires July 2003 [Page 2]
Internet Draft draft-kuwahara-cl-tunneling-vpn-01.txt January 2003
1. Introduction
This document describes a connectionless (CL) tunneling architecture
that is applicable to layer 3 PE-based virtual private networks [L3-
PPVPN-FR]. It also describes protocols for implementing the CL
tunneling architecture. A prominent feature of this architecture is
establishing VPN tunnels [L3-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 [L3-PPVPN-FR]
are called a CL tunnel and a core network, respectively. The design
objectives of this architecture are scalability and reliability.
This architecture is based on the reference model for the layer 3
PE-based VPN defined in [L3-PPVPN-FR]. It assumes that an SP network
consists of Provider Edge (PE) devices, which accommodate Customer
Edge (CE) devices, and Provider (P) routers, which interconnect PEs
but do not provide VPN-specific functionality. A PE device 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 layer 3 PE-based VPNs 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 problem 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. Moreover,
when CL tunnels are set in a hub-and-spoke topology, a cut-through
tunnel is dynamically created when necessary.
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 (described in appendix A) that
enables explicit routing in order to support these features.
The scope of the CL tunneling architecture is focused on the
operation of CL tunnels, so it describes the protocol suite to be
applied to the CL SP network and CL tunnel control. Also, the
architecture does not specify any restriction on other protocols,
i.e., VPN membership discovery protocols and routing protocols, which
are out of the scope of this document. The same applies to the usage
of Diffserv [RFC2474].
Section 2 describes the CL tunneling architecture, and section 3
describes protocols applied to this architecture based on IPv6
Kuwahara et al. Expires July 2003 [Page 3]
Internet Draft draft-kuwahara-cl-tunneling-vpn-01.txt January 2003
[RFC2460]. In addition, Appendix A describes an example
configuration for the addressing used in CL networks enabling
efficient operation of VPNs. Appendix B describes an example
configuration for the hub and spoke topology with multiple hubs.
Appendix C specifies an ATM-based protocol suite that makes use of
cell-based encapsulation to improve forwarding performance.
2. Connectionless Tunneling Architecture
This section describes a CL tunneling architecture that is applicable
to layer 3 PE-based VPNs. In this architecture, the same names are
used for those entities already defined in [L3-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 July 2003 [Page 4]
Internet Draft draft-kuwahara-cl-tunneling-vpn-01.txt January 2003
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
router or PE device 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, it 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
a key. Then, the egress PE forwards the IP packet toward the
Kuwahara et al. Expires July 2003 [Page 5]
Internet Draft draft-kuwahara-cl-tunneling-vpn-01.txt January 2003
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), which is described in Section 3.2.
<=====>: CL tunnel for default route forwarding
<----->: CL tunnel for cut-through route forwarding
PE Device P Router DF
+---------+ +------------+ +---------+
| +-----+ | | | | +-----+ |
| | VFI |<================================>| | |
| | |<---------------+ | | | VFI | |
| +-----+ | | | | | | | |
+---------+ | | | | | | |
PE Device | | | | | | |
+---------+ | | | | | | |
| +-----+ | | | | | | | |
| | VFI |<---------------+ | | | | |
| | |<================================>| | |
| +-----+ | | | | | | |
+---------+ | | | | | |
PE Device | | | | | |
+---------+ | | | | | |
| +-----+ | | | | | | |
| | VFI |<================================>| | |
| +-----+ | | | | +-----+ |
+---------+ +------------+ +---------+
Figure 2.2 Hub and Spoke Topology
3. Protocol Suite
This section describes the protocol suite to be applied to the
architecture described in Section 2.
3.1 Overview
Kuwahara et al. Expires July 2003 [Page 6]
Internet Draft draft-kuwahara-cl-tunneling-vpn-01.txt January 2003
The CL tunneling architecture specifies the protocol suite to be
applied to the connectionless SP network and CL tunnel control.
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
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].
CTCP 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 (CTCP)
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 July 2003 [Page 7]
Internet Draft draft-kuwahara-cl-tunneling-vpn-01.txt January 2003
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
Operation ID: Identifies operations in the message.
Kuwahara et al. Expires July 2003 [Page 8]
Internet Draft draft-kuwahara-cl-tunneling-vpn-01.txt January 2003
16-bit unsigned integer.
Address Type: Protocol number, which indicates
the type of 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.
128-bit unsigned integer.
Descriptions:
A Tunnel Redirection Notification message (Type=1, Code=1) is used by
a VFI to request an ingress VFI to forward tunneled IP packets with
the indicated address prefix via the 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 describes 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 a 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. The Prefix Length and Resolved IPv6 Address fields contain
the prefix lengths of the target and PE addresses 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
forwarded through the cut-through CL tunnel.
Kuwahara et al. Expires July 2003 [Page 9]
Internet Draft draft-kuwahara-cl-tunneling-vpn-01.txt January 2003
(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 but
not the Resolved IPv6 Address or 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 via 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 PE
Kuwahara et al. Expires July 2003 [Page 10]
Internet Draft draft-kuwahara-cl-tunneling-vpn-01.txt January 2003
3.2.3 Implementation Guidelines
This section describes guidelines for implementing a VFI for CTCP.
They enable the routing-loop-free implementation of CTCP described in
the previous section.
As shown in Figure 3.1, the VFI within a PE consists of two types of
tables: the Core Forwarding Table (CFT) is used for forwarding a
packet to the core network and the Access Forwarding Table (AFT) is
used for forwarding a packet to the access network. CFT consists of
an entry for the DF and tunnel redirection entries for egress PEs.
AFT consists of entries for CEs.
Entries in the AFT and CFT, except for entries for egress PEs, are
controlled by a routing protocol but never controlled by CTCP. On
the other hand, entries for egress PEs are controlled by CTCP but
never controlled by a routing protocol. In this way, a routing
protocol calculates routes independently of entries for egress PEs
controlled by CTCP.
When a VFI in a PE receives a packet from the core network, it
searches the AFT and forwards the received packet to the access
network. If the destination address in a packet does not hit an AFT
entry, the VFI discards the packet and sends a Tunnel Purge
Notification message to the ingress VFI. Also, it is necessary to
prohibit the forwarding of the packet, received from the core
network, back to the core network.
When a VFI in a PE receives a packet from the access network, it
searches the CFT, except for the entry for the DF, and forwards the
received packet to the core network. If a packet does not hit an
entry, then the VFI looks up the entry for the DF and forwards the
packet to the core network. The VFI additionally searches the AFT
and forwards the packet to the access network when its own core
network address is resolved by searching the CFT.
When a VFI in a PE receives ICMP destination unreachable from the
core network, it must delete the associated entry for the PE in the
CFT.
Kuwahara et al. Expires July 2003 [Page 11]
Internet Draft draft-kuwahara-cl-tunneling-vpn-01.txt January 2003
<-- Access Network VFI Core Network -->
+-----------------------------------------------------+
| CFT: Core Forwarding Table |
| +-------------------------------------------------+ |
| | Entries for Egress PEs | |
| | (Tunnel Redirection Entries) | |
->--->--->-+->--->--->--->--->--->--->--->--->--->--->-+->--->--->
| | | <Miss> <Return to CEs> | | |
| +--|-------------------------------------------|--+ |
| | V Entry for the DF | | |
| | +->--->--->--->--->--->--->--->--->--->--->-+->--->--->
| +----------------------------------------------|--+ |
| | |
| AFT: Access Forwarding Table | |
| +----------------------------------------------|--+ |
| | Entries for CEs V | |
<---<---<---<---<---<---<---<---<---<---<---<---<---<-+-<---<---
| +-------------------------------------------------+ |
+-----------------------------------------------------+
Figure 3.4 VFI in PE
The VFI within a DF consists of only CFT. The CFT consists of
entries for egress PEs which are controlled by a routing protocol but
never controlled by CTCP.
When a VFI within a DF receives a packet from the core network, it
searches the CFT and forwards the packet to the core network. At the
same time, the VFI sends a Tunnel Redirection Notification message to
the ingress VFI. If a packet does not hit an entry, the VFI discards
the packet and sends a Tunnel Purge Notification message to the
ingress VFI.
VFI Core Network -->
+-----------------------------------------------------+
| CFT: Core Forwarding Table |
| +-------------------------------------------------+ |
| | Entries for Egress PEs | |
| | +<---<---<---<---<---<---<---<---<---
| | | | |
| | V <Hit> | |
| | +--->--->--->--->--->--->--->--->--->
| +-------------------------------------------------+ |
+-----------------------------------------------------+
Figure 3.5 VFI in DF
The same Tunnel Redirection/Purge message must not be sent many times
Kuwahara et al. Expires July 2003 [Page 12]
Internet Draft draft-kuwahara-cl-tunneling-vpn-01.txt January 2003
by DFs/PEs during a short period. This can be prevented by setting a
flag on the entries that have been used once for a Tunnel
Redirection/Purge message by DFs/PEs, so that they are not resent.
The implementation should also be able to expire this flag so that
these messages can be produced again after a period of time.
The load of an egress PE may be balanced among multiple PEs by using
a routing protocol in a DF. Here, the DF must not send a Tunnel
Redirection message triggered by the packet sent to the egress PE.
This operation can also be implemented by setting a flag on the
entries for the egress PE. However, this flag must not expire.
IP routes among DFs and PEs may be controlled by routing protocols in
the same manner as ordinary routers. However, in order to take
advantages of the hub and spoke topology, the entry in a CFT of a
PE's VFI should be set statically as a default route for a DF,
instead of being set by using routing information distributed from
the DF.
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 the
GMN-CL (Global Megamedia Networks based on Connectionless
Technologies) project in NTT. The authors would like to acknowledge
O. Tabata and T. Iwase of NEC Corporation, M. Inami and E. Takahashi
of Fujitsu Limited, H. Takenoshita and Y. Araki of Oki Electric
Industry Company, and K. Kitami and J. Sumimoto of NTT Corporation
for discussions and comments on the specification and
implementations.
6. Normative References
[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.
Kuwahara et al. Expires July 2003 [Page 13]
Internet Draft draft-kuwahara-cl-tunneling-vpn-01.txt January 2003
[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.
[RFC2373] Hinden, R. and Deering, S., "IP Version 6 Addressing
Architecture," RFC 2373, July 1998.
7. Informative References
[L3-PPVPN-FR] Callon, R. and Suzuki, M. Eds, "A Framework for
Layer 3 Provider Provisioned Virtual Private Networks,"
Internet-draft <draft-ietf-ppvpn-framework-05.txt>,
April 2002.
[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.
8. 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
Masaki Tanikawa
NTT Corporation,
3-9-11, Midori-cho,
Kuwahara et al. Expires July 2003 [Page 14]
Internet Draft draft-kuwahara-cl-tunneling-vpn-01.txt January 2003
Musashino-shi, Tokyo 180-8585, Japan
Email: tanikawa.masaki@lab.ntt.co.jp
Muneyoshi Suzuki
NTT Corporation,
3-9-11, Midori-cho,
Musashino-shi, Tokyo 180-8585, Japan
Email: suzuki.muneyoshi@lab.ntt.co.jp
Kuwahara et al. Expires July 2003 [Page 15]
Internet Draft draft-kuwahara-cl-tunneling-vpn-01.txt January 2003
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 the 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 network 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 July 2003 [Page 16]
Internet Draft draft-kuwahara-cl-tunneling-vpn-01.txt January 2003
Appendix B: Example Configuration Scheme for the Hub and Spoke Topology
with Multiple Hubs
This appendix describes an example configuration for the hub and
spoke topology with multiple hubs(DFs).
Multiple VFIs in DFs and PEs may form any type of topology, and IP
routes among them may be controlled by a routing protocol, which is
the same as an ordinary router network. However, in the CL tunneling
architecture, the hub and spoke topology is preferable in order to
take advantage of CTCP.
One of the reasons for introducing multiple DFs is to maintain
reachability to the egress VFI in a PE in the case of a DF's failure.
By introducing two DFs and connecting them each other, the hub and
spoke topology may be duplicated and the DF becomes redundant. In
this case, each VFI in a PE should have primary and secondary default
routes associated with each DF, and each PE should have a different
DF as the primary route so that loads may be balanced between two
DFs. Here, switching to the secondary DF may occur when the routing
protocol detects a failure between the primary DF and a PE.
Even when the ingress PE does not detect the failure, the primary DF
may detect it and the packet may be forwarded to the egress PE via
the secondary DF. Then the primary DF would send a Tunnel
Redirection message to the ingress PE so that the packet may be
forwarded via the cut-through tunnel to the secondary DF. After the
ingress PE receives the redirection message from the secondary DF,
the packet may be forwarded to the egress PE via a cut-through tunnel
from the ingress PE to the egress PE. In this way, an ingress PE may
receive a Tunnel Redirection message for an egress PE regardless of
the failure.
The other reason for introducing multiple DFs is to lighten the load
on the DF when there is a large number of PEs to accommodate. In
this case, PEs may be divided into groups to form multiple hub and
spoke topologies, and the VFI in a DF of one topology may be
connected to those in the others. When the number of DFs is
relatively small, the VFIs in DFs may be configured in a mesh
topology, whereas in the case of a large number of DFs, they should
also be configured in a hub and spoke topology.
In both of the above cases, the hub and spoke topology is configured
among VFIs in PEs and DFs, so each VFI in a PE may select any DF as a
hub.
By introducing multiple DFs as described above, a DF may receive a
Tunnel Redirection/Purge message in the same manner as a PE.
Kuwahara et al. Expires July 2003 [Page 17]
Internet Draft draft-kuwahara-cl-tunneling-vpn-01.txt January 2003
However, a CFT in a VFI of the DF has only the entries controlled by
routing protocols; it has no entries controlled by CTCP. Therefore,
the DF ignores received Tunnel Redirection/Purge messages.
Kuwahara et al. Expires July 2003 [Page 18]
Internet Draft draft-kuwahara-cl-tunneling-vpn-01.txt January 2003
Appendix C: ATM-based Protocol Suite
C.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.
C.2 Overview
Figure C.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 C.3 shows protocol stacks of the
ATM-based protocol suite described in this appendix. Section C.4
describes the usage of the ATM protocol in the protocol suite.
Section C.5 specifies the structure of an AAL5-CPCS PDU encapsulating
a core network protocol PDU. The ATM-based core network protocol is
specified in section C.6 and used for CL tunneling without a
tunneling establishment procedure over ATM networks. Section C.7
describes scheme for encapsulating/decapsulating an IP packet from a
user as a core network protocol PDU defined in Section C.5. To
control the core network applying the ATM-based core network
protocol, the Core Control Message Protocol (CCMP) is used; it is
specified in section C.8. CCMP is also used to control the tunnel
configuration.
{Section C.8}
| |
V V
+-------------+-------------+-------------+
|CCMP for |CCMP for | IP |
|tunnel |core network | |
|configuration|control | |
+-------------+-------------+-------------|<--{Section C.7}
| ATM-based core network protocol |<--{Section C.6}
+-----------------------------------------+<--{Section C.5}
| ATM |<--{Section C.4}
+-----------------------------------------+
Figure C.1 ATM-based Protocol Suite for the CL Tunneling Architecture
Kuwahara et al. Expires July 2003 [Page 19]
Internet Draft draft-kuwahara-cl-tunneling-vpn-01.txt January 2003
C.3 Protocol Stacks
C.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 C.8.
C.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 C.2 Protocol Stack of the Forwarding Plane
Kuwahara et al. Expires July 2003 [Page 20]
Internet Draft draft-kuwahara-cl-tunneling-vpn-01.txt January 2003
C.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 C.3 Protocol Stack of the Core Network Control Plane
C.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 C.4 Protocol Stack of the CL Tunneling Plane
C.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 July 2003 [Page 21]
Internet Draft draft-kuwahara-cl-tunneling-vpn-01.txt January 2003
specification [I.363.5]. The AAL5 message mode shall be used.
C.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) | PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
~ 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-5E (IANA).
PID: 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 July 2003 [Page 22]
Internet Draft draft-kuwahara-cl-tunneling-vpn-01.txt January 2003
CRC: A CRC 32 is calculated for the entire AAL5-CPCS
PDU except for the CRC field itself.
C.6 ATM-based Core Network Protocol
C.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 July 2003 [Page 23]
Internet Draft draft-kuwahara-cl-tunneling-vpn-01.txt January 2003
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 C.6.2 for the internal
structure.
Destination Core Network Address:
128 bits. See Section C.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.
C.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 C.6.3 for the internal structure.
VPN ID: 64 bits.
See Section C.6.4 for the internal structure.
Kuwahara et al. Expires July 2003 [Page 24]
Internet Draft draft-kuwahara-cl-tunneling-vpn-01.txt January 2003
C.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: identifies the serving provider.
CC: 10-bit unsigned integer.
Country Code: identifies 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: identifies an area in the indicated
country.
PE/DF Group ID:
14-bit unsigned integer.
Identifies a physical node supporting a group of
PEs/DFs 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.
C.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 July 2003 [Page 25]
Internet Draft draft-kuwahara-cl-tunneling-vpn-01.txt January 2003
C.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 C.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 C.2. The core network
protocol header is also encapsulated with the other LLC/SNAP header.
The encapsulation scheme is shown in Figure C.5. Here, the payload
of the 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 C.5 Core Encapsulation
C.8 Core Control Message Protocol
The Core Control Message Protocol (CCMP) specified here supports core
network control and tunnel configuration.
Kuwahara et al. Expires July 2003 [Page 26]
Internet Draft draft-kuwahara-cl-tunneling-vpn-01.txt January 2003
C.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 C.1.
Table C.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|
+---------------++----------------------------------+----+----+
C.8.2 ECHO Request
This message is transmitted to test the reachability of 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 July 2003 [Page 27]
Internet Draft draft-kuwahara-cl-tunneling-vpn-01.txt January 2003
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.
C.8.3 ECHO Reply
This message is transmitted to confirm the reachability of 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 July 2003 [Page 28]
Internet Draft draft-kuwahara-cl-tunneling-vpn-01.txt January 2003
C.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.
C.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 July 2003 [Page 29]
Internet Draft draft-kuwahara-cl-tunneling-vpn-01.txt January 2003
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.
C.8.6 Tunnel Purge Notification
Kuwahara et al. Expires July 2003 [Page 30]
Internet Draft draft-kuwahara-cl-tunneling-vpn-01.txt January 2003
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 C.1 for the allocation of values.
CODE: 8-bit unsigned integer. The Tunnel Purge
Notification message class. See Table C.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 July 2003 [Page 31]
Internet Draft draft-kuwahara-cl-tunneling-vpn-01.txt January 2003
Full Copyright Statement
Copyright (C) The Internet Society (2002). 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 July 2003 [Page 32]
