Network Working Group T. Kuwahara Internet Draft J. Murayama Expires: July 2003 M. Tanikawa M. Suzuki NTT Corporation January 17, 2003 Scalable Connectionless Tunneling Architecture and Protocols for VPNs 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-ietf-ppvpn-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-ietf-ppvpn-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-ietf-ppvpn-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-ietf-ppvpn-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-ietf-ppvpn-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-ietf-ppvpn-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-ietf-ppvpn-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-ietf-ppvpn-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-ietf-ppvpn-cl-tunneling-vpn-01.txt January 2003 (2) Tunnel Redirection Notification +------------+ +------------------|Intermediate| | +------------->| DF (VFI) |------------+ | | (1) Default +------------+(1) Default | | | Forwarding Forwarding | | | | V | 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 | | | | | | 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-ietf-ppvpn-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-ietf-ppvpn-cl-tunneling-vpn-01.txt January 2003 <-- Access Network VFI Core Network --> +-----------------------------------------------------+ | CFT: Core Forwarding Table | | +-------------------------------------------------+ | | | Entries for Egress PEs | | | | (Tunnel Redirection Entries) | | ->--->--->-+->--->--->--->--->--->--->--->--->--->--->-+->--->---> | | | | | | | +--|-------------------------------------------|--+ | | | 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 | | | | +--->--->--->--->--->--->--->--->---> | +-------------------------------------------------+ | +-----------------------------------------------------+ 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-ietf-ppvpn-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-ietf-ppvpn-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 , 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-ietf-ppvpn-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-ietf-ppvpn-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-ietf-ppvpn-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-ietf-ppvpn-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-ietf-ppvpn-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-ietf-ppvpn-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-ietf-ppvpn-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-ietf-ppvpn-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-ietf-ppvpn-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-ietf-ppvpn-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-ietf-ppvpn-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-ietf-ppvpn-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-ietf-ppvpn-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-ietf-ppvpn-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-ietf-ppvpn-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-ietf-ppvpn-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-ietf-ppvpn-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-ietf-ppvpn-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]