Softwire Working Group J. Wu Internet-Draft Y. Cui Expires: December 19, 2006 X. Li Tsinghua University C. Metz G. Nalawade S. Barber P. Mohapatra Cisco Systems, Inc. June 17, 2006 A Framework for Softwire Mesh Signaling, Routing and Encapsulation across IPv4 and IPv6 Backbone Networks draft-wu-softwire-mesh-framework-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on December 19, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The softwires mesh problem identfies a requirement for a generalized, Wu, et al. Expires December 19, 2006 [Page 1] Internet-Draft Softwires Mesh Framework June 2006 network-based client IP(x)-over-backbone IP(y) solution in support of the transition to IPv6. Connectivity between islands of IPv6, IPv4 or IPv6/v4 networks will be enabled across a single IPv4 or IPv6 backbone network employing IP (or MPLS) tunnels called softwires. This solution will re-use where appropriate existing multi-address family routing mechanisms such as the Border Gateway Protocol as well as existing IP (and label) tunnel encapsulation schemes. The intent is to encourage multiple, inter-operable vendor implementations in the hope operators will find it easier and more attractive to support the transition to IPv6. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Wu, et al. Expires December 19, 2006 [Page 2] Internet-Draft Softwires Mesh Framework June 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.1. IPv6-over-IPv4 Scenario . . . . . . . . . . . . . . . . . 12 3.2. IPv4-over-IPv6 Scenario . . . . . . . . . . . . . . . . . 14 4. Reference Models . . . . . . . . . . . . . . . . . . . . . . . 17 4.1. Softwire Mesh Reference Model . . . . . . . . . . . . . . 17 4.2. Entities of the Softwire Mesh Reference Model . . . . . . 17 4.3. ABFR Reference Model . . . . . . . . . . . . . . . . . . . 18 4.4. Entities of the AFBR Reference Model . . . . . . . . . . . 19 4.5. Comments on Single AF AFBR Reference Models . . . . . . . 20 5. Softwire Signaling . . . . . . . . . . . . . . . . . . . . . . 22 5.1. SW Encapsulation Sets . . . . . . . . . . . . . . . . . . 22 5.2. BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.3. non-BGP Signaling . . . . . . . . . . . . . . . . . . . . 24 6. Softwire Routing and Tunnel Selection . . . . . . . . . . . . 25 6.1. Advertising Client AF Access Island Reachability . . . . . 25 6.2. Tunnel Selection . . . . . . . . . . . . . . . . . . . . . 26 6.2.1. Softwire Next_Hop . . . . . . . . . . . . . . . . . . 26 6.2.2. Next_Hop Overlay Addressing . . . . . . . . . . . . . 28 6.3. Comments on a BGP-free Core . . . . . . . . . . . . . . . 28 7. Softwire Forwarding and Tunnel Encapsulations . . . . . . . . 30 7.1. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . 30 7.2. Encapsulations . . . . . . . . . . . . . . . . . . . . . . 30 8. Softwire OAM and MIBs . . . . . . . . . . . . . . . . . . . . 31 8.1. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 8.2. MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 9. Softwire Multicast . . . . . . . . . . . . . . . . . . . . . . 32 10. Inter-AS Considerations . . . . . . . . . . . . . . . . . . . 34 10.1. Option A: Back-to-Back AFBRs . . . . . . . . . . . . . . . 34 10.2. Option B: EBGP redistribution of AF(i) prefixes . . . . . 34 10.3. Option C: Multihop EBGP distribution of AF(i) prefixes . . 35 11. Security Considerations . . . . . . . . . . . . . . . . . . . 37 12. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 38 Wu, et al. Expires December 19, 2006 [Page 3] Internet-Draft Softwires Mesh Framework June 2006 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 13.1. Normative References . . . . . . . . . . . . . . . . . . . 39 13.2. Informative References . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 Intellectual Property and Copyright Statements . . . . . . . . . . 43 Wu, et al. Expires December 19, 2006 [Page 4] Internet-Draft Softwires Mesh Framework June 2006 1. Introduction The versatility of ISP and corporate IP backbone networks has been enhanced over the last few years by their ability to provide routing services to their attached constituent client networks. For example RFC4364 defines a method for providing network-based IPv4 VPN routing and forwarding across an MPLS backbone. This involves definition of a new address family (AF) (VPNv4), distribution of the client VPNv4 prefixes between the provider's interested edge routers (called provider edge or PE routers) and encapsulation/decapsulation of the client's IPv4 packets in labels for transit across the backbone network. The provider can now offer inter-client site IPv4 routing and forwarding services. The provider operates a uniform backbone network based on MPLS label switching. Their cadre of PE routers performs the tasks of client AF prefix/next-hop distribution and switching client packets to and from backbone label switched paths (LSP). This solution has proven to be quite scalable as the interior network needs only store next-hop reachability to the PE routers and while the PE routers employ BGP and its attendant scaling functions (e.g. route reflectors, extended communities) for conveying client AF prefix reachability. At the same time and for a variety of technical, economical, political and operational reasons, some of these same ISP and enterprise backbone providers are being asked to support IPv6 routing and forwarding across their IPv4-based backbone networks. Providers can employ one of the existing IPv6-over-IPv4 transition tunnel schemes that have been defined and in some cases implemented through the years. The drawbacks of these various schemes (of which there are too many to enumerate here) is that some are are limited in their functional scope (e.g. may only work in LAN environments), some require extensive manual configuration and thus do not scale and some require special IPv6 addressing schemes to work effectively. Another option available to providers is to deploy a network-based IPv6 VPN routing and forwarding service and tunnel customer IPv6 VPN packets across an MPLS backbone network. This works in a manner similar to the aforementioned IPv4 VPN service except now the PE routers are distributing and storing prefixes/next-hops belonging to an IPv6 VPN AF. This solution inherits the scaling properties of the IPv4 VPN solution and the backbone remains MPLS. A drawback of the IP VPN solutions is that they mandate client AF prefixes be stored and distributed as VPN address families (AFI=x/ SAFI=128) in VPN-specific routing tables. For topological, operational or other reasons the provider may not wish to configure VPN routing tables on their PE routers that are necessary to support Wu, et al. Expires December 19, 2006 [Page 5] Internet-Draft Softwires Mesh Framework June 2006 these solutions. Another drawback is the implicit limitation on the type of forwarding supported in the backbone network. Most implementations require the backbone and PE routers to support MPLS. Some implementations can accommodate IP VPN forwarding across IP-based tunnels (where the backbone is IPv4 only). Interoperability could be an issue and the choices of IP tunnel encapsulation/decapsulation performed by the PE routers may also be limited [draft-ietf-l3vpn-gre-ip-2547]. Up until this point, the assumption is that the provider's backbone is IPv4 or MPLS and the client networks are IPv4 or IPv6. That assumption is no longer valid. Indeed there are operators right now who have deployed (or plan to deploy in the near future) a native IPv6 backbone network and who require the ability to support client IPv4 routing and forwarding across such a backbone network. The dilemma faced by these IPv6 backbone operators is that their options for interoperable IPv4-over-IPv6 tunneling are limited and the operational burden associated with a solution that solves the problem, namely point-to-point tunnel provisioning [RFC2473], is large and costly. Moreover it is either too expensive or just not practical to require dual-stacks on the hosts operating in the client networks. Thus the requirement to support a scalable and interoperable IPv4-over-IPv6 routing and forwarding service presents itself. Based on this discussion it is now possible to outline the functions for a generalized, network-based client IP AF(i)-over-backbone IP AF(j)routing and forwarding solution (where (i) and (j) denote different AF's): o Backbone network of IP AF(j) forwards packets with a header or labels based on IP AF(j) o Local PE routers discover a set of tunnel encapsulation parameters and tunnel end-points of IP AF(j) located on remote PE routers. o Mesh of inter-PE tunnels with a tunnel header based on IP AF (j) are dynamically established. Client IP AF(i) packets will be directed into the appropriate tunnel based on destination client IP AF(i) prefixes and a next_hop reachable through the other end of the tunnel. o Client IP AF (i) prefixes, AF(i) next_hops and tunnel identifier/ next-hop addresses are stored on local PE routers and distributed in a scalable fashion to interested remote PE routers. The purpose of the tunnel identifier/next-hop address is to bind the advertised client IP AF (i) prefix/next_hop with an established Wu, et al. Expires December 19, 2006 [Page 6] Internet-Draft Softwires Mesh Framework June 2006 inter-PE tunnel leading to that prefix that terminates in the tunnel next-hop address. o Packets belonging to client IP AF(i) are encapsulated in backbone AF(j)-based tunnel headers (IP or labels) and forwarded across the backbone AF(j) network. These functions operate with an interchangeable mix of different AF and tunnel encapsulation types. For example client IP AF(i) prefixes could be native IPv4, native IPv6, VPN IPv4 or VPN IPv6. Native means the prefixes are stored in a global table with a SAF=1 and VPN means prefixes are stored in VPN routing and forwarding tables with a SAF=128. The backbone IP AF(j) could be native IPv6 or native IPv4. The tunnel encapsulation types could be IP-IP [RFC2473], GRE [RFC2784], L2TPv3 [RFC3931] and certainly others are possible. It is even possible that MPLS tunnels could be used to progress client AF(i) packets across the IP AF (j) backbone network consistent with the IP VPN solutions discussed earlier. These functions align with a solution to address the requirements to the softwire mesh problem as set forth in [draft-ietf-softwire-problem- statement]. Providers who operate IPv4 or IPv6 backbone networks will require a generalized, scalable and interoperate set of mechanisms to tunnel, based on client IP AF reachability, packets belonging to one or multiple IPv4 or IPv6 address families across their respective IPv4 or IPv6 backbone networks. A byproduct of this solution is the notion of a BGP-free core. Core routers located in the interior of the network need only to provide reachability to themselves and the peripheral set of PE routers via an interior gateway protocol (IGP); all client AF prefixes including the Internet routing table are maintained on the PE routers. A routing decision for an Internet prefix performed at an ingress PE router resolves a BGP next_hop to a tunnel leading to the egress PE and the packet is transparently tunneled across the core. The tunnel in this case is referred to as a softwire. A set of softwires established between PE routers (termed address family border routers or AFBRs in this document) is referred to as a softwire mesh. Softwire tunnel configuration information, client IP AF reachability and softwire identifier/next_hops are automatically distributed between participating AFBRs. Client IP AF packets are tunneled across the softwire mesh between local and remote AFBRs based on client IP AF reachability information and the associated softwire. The objective of this document is to describe a framework for Wu, et al. Expires December 19, 2006 [Page 7] Internet-Draft Softwires Mesh Framework June 2006 softwire mesh signaling, routing and encapsulation across IPv4 or IPv6 backbone networks. It defines a generalized, network-based client IP(x)-over-backbone IP(y) solution in support of the transition to IPv6. Connectivity between islands of IPv6, IPv4 or dual-stack IPv6/v4 networks will be enabled across a single IPv4 or IPv6 backbone network employing IP (or MPLS) tunnels called softwires. This solution will re-use where appropriate existing multi-address family routing mechanisms such as the Border Gateway Protocol as well as existing IP (and label) tunnel encapsulation schemes. The intent is to encourage multiple, inter-operable vendor implementations in the hope operators will find it easier and more attractive to support the transition to IPv6. Wu, et al. Expires December 19, 2006 [Page 8] Internet-Draft Softwires Mesh Framework June 2006 2. Terminology The following terminology will used in this document. Address Family (AF) IPv4 or IPv6. Presently defined values for this field are specified in [RFC1700] (see the Address Family Numbers section). AF(i), AF(j) Notation used to indicate that prefixes, a node or network only deal with a single IP AF. AF(i,j) Notation used to indicate that a node is dual-stack (e.g. runs both IPv4 and IPv6) or that a network is composed (at least partially) of dual-stack nodes. Address Family Border Router (AFBR) A dual-stack router that interconnects two networks that use either the same or different address families. An AFBR forms peering relationships with other AFBRs, adjacent core routers and attached CE routers, performs softwire discovery and signaling, advertises client AF(i) reachability information and encapsulates/decapsulates customer packets in softwire transport headers. AF Access Island A single IP AF(i) or dual-stack IP AF (i,j) client access network connected to one (single-homed) or more than one (multi-homed) upstream AFBRs. Customer Edge (CE) A router located inside AF access island that peers with other CE routers within the access island network and with one or more upstream AFBRs Client AF Prefixes IP AF(i) or AF(j) prefixes originating inside an AF access island. Single AF Transit Core A single AF(j) transit core composed of IPv4 or IPv6 core routers Wu, et al. Expires December 19, 2006 [Page 9] Internet-Draft Softwires Mesh Framework June 2006 surrounded by a periphery of dual stack AF (i,j) AFBRs. The transit core forward packets with IP AF(j) headers or labels derived from an IP AF(j) control plane. Softwire (SW) A "tunnel" that is created on the basis of a control protocol setup between softwire endpoints with shared point-to-point or multipoint- to-point state. Softwires are generally dynamic in nature and when formed over a backbone network in a mesh configuration are considered very long-lived. Softwire Transport Header AF (STH AF) The address family of the outermost IP header of a softwire. This will either be IPv4, IPv6 or labels derived from one or the other. If the softwire employs MPLS label encapsulation then the STH AF is an implicit IPv4 with the assumption that most MPLS deployments currently employ an IPv4 control plane. This could change in the future when native IPv6 backbone networks and their elements implement an MPLS control and forwarding plane based on IPv6. Softwire Payload Header AF (SPH AF) The address family of the IP headers being carried within a softwire. Note that additional "levels" of IP headers may be present if (for example) a tunnel is carried over a softwire - the key attribute of SPH AF is that it is directly encapsulated within the softwire and the softwire endpoint will base forwarding decisions on the SPH AF when a packet is exiting the softwire. Softwire Encapsulation Set (SW-Encap) A softwire encapsulation set contains tunnel header parameters, order of preference of the tunnel header types and the expected payload types (e.g. IPv4) carried inside the softwire. Softwire Next_Hop (SW-NHOP) This attribute accompanies client AF reachability advertisements and is used to reference a softwire on the ingress AFBR leading to the specific prefixes. It contains a softwire identifier value and a softwire next_hop IP address denoted as . Its existence in the presence of client AF prefixes (in advertisements or as entries in a routing table) infers the use of softwire to reach that prefix. Subsequent Address Family (SAF) Wu, et al. Expires December 19, 2006 [Page 10] Internet-Draft Softwires Mesh Framework June 2006 Additional information about the type of the Network Layer Reachability Information (e.g. unicast or multicast). Wu, et al. Expires December 19, 2006 [Page 11] Internet-Draft Softwires Mesh Framework June 2006 3. Requirements The requirements for addressing the softwire mesh problem are described in [draft-ietf-softwire-problem-statement]. In addition the framework outlined in this document attempts to: o Leverage and reuse existing protocols and practices where appropriate. L3VPN [RFC4110] solutions already provide multi-AF routing across homogenous IP or MPLS backbones and to that extent we wish to leverage that effort. On the tunnel encapsulation side, nothing new is needed; the existing methods are sufficient for our purposes. o AF and Tunnel Encap Agnostic. Basically packets belonging to any IP AF, native and including the VPN variants, should be able to be tunneled across an IPv4 or IPv6 backbone using different encapsulation techniques including MPLS labels. o Keep it simple while providing the provider with maximum flexibility. In summary the basic requirement is to support a generalized, network-based solution supporting IPv6-over-IPv4 and IPv4-over-IPv6 scenarios employing different IP (or label) tunneling encapsulation types. 3.1. IPv6-over-IPv4 Scenario The first category of scenarios that must be addressed by the softwire mesh framework is client IPv6-over-backbone IPv4. Figure 1 illustrates a number of IPv6 access island networks connected to an IPv4 transit core. The objective of the softwire mesh is to provide a scalable, network-based IPv6 routing and forwarding service that operates over the IPv4 transit core. It should be noted here that the IPv4 transit core may run MPLS label switching. That is not a problem and one could easily see how the softwire mesh could be composed of a set of point-to-point or multipoint-to-point label switched paths (LSP). In addition an access network does not necessarily have to be IPv6 only; it could be dual-stack or IPv4-based. The general problem of IPv6 connectivity across IPv4 networks has been addressed through the years using a number of different tunneling mechanisms, some provisioned manually, others based on special addressing. More recently MPLS VPNs have been extended to support IPv6 VPN services across an MPLS backbone. Wu, et al. Expires December 19, 2006 [Page 12] Internet-Draft Softwires Mesh Framework June 2006 The softwire mesh framework will employ elements of those solutions with the key differences being a) tunnels are automatically built; b) any tunnel encapsulation scheme is permitted and; c) client AF prefix distribution and processing is not VPN-centric. That is to say that the solution will support existing VPN routing and forwarding capabilities but it is not mandatory. Wu, et al. Expires December 19, 2006 [Page 13] Internet-Draft Softwires Mesh Framework June 2006 +--------+ +--------+ | IPv6 | | IPv6 | | AF | | AF | | Access | | Access | | Island | | Island | +--------+ +--------+ | \ / | | \ / | | \ / | | X | | / \ | | / \ | | / \ | +--------+ +--------+ | AFBR | | AFBR | +--| IPv4/6 |---| IPv4/6 |--+ | +--------+ +--------+ | +-------+ | | +-------+ | IPv4 | | | | IPv4 | | AF | | | | AF | | Access|-------| IPv4 |-------| Access| | Island| | Transit Core | | Island| +-------+ | | +-------+ | | | +--------+ +--------+ | +--| AFBR |---| AFBR |--+ | IPv4/6 | | IPv4/6 | +--------+ +--------+ | \ / | | \ / | | \ / | | X | | / \ | | / \ | | / \ | +--------+ +--------+ | IPv6 | | IPv6 | | AF | | AF | | Access | | Access | | Island | | Island | +--------+ +--------+ Figure 1 IPv6-over-IPv4 Scenario 3.2. IPv4-over-IPv6 Scenario The second category of scenarios that must be addressed by the Wu, et al. Expires December 19, 2006 [Page 14] Internet-Draft Softwires Mesh Framework June 2006 softwire mesh framework is client IPv4-over-backbone IPv6. Figure 2 illustrates a number of IPv4 access island networks connected to an IPv6 transit core. The objective of the softwire mesh is to provide a scalable, network-based IPv4 routing and forwarding service that operates over the IPv6 transit core. This is perhaps the more interesting scenario to look at for several reasons. First it is clearly an emerging and significant requirement. As mentioned native IPv6 backbones are being deployed and there is clearly a large legacy of IPv4 networks and applications that can and should operate across this new transit core. Second the notion of supporting dynamic client IP AF routing and forwarding across native IPv6 networks has frankly not been implemented by vendors. A provider would have a tough time finding a BGP-based VPN routing and forwarding solution that operates across a native IPv6 backbone. The third area of interest here involves the problem of the common AFI/SAFI shared by network layer reachability information (NLRI) and next_hop address fields contained in BGP prefix advertisements. Simply put [RFC2858] states that the AFI/SAFI of the NLRI and next_hop fields contained in a BGP prefix advertisement must be the same. Clever workarounds (for operation across IPv4 backbone networks only) have been devised through the years to take VPN or IPv6 NLRIs and generate an AFI/SAFI-matching next-hop address that is really an IPv4 address in disguise. This was doable because the larger next_hop field was big enough to hold a padded out IPv4 address (the VPN case) or an IPv4-compatible IPv6 (the IPv6 case). A PE router performs the NLRI lookup that yields the next-hop address which then can be converted to an IPv4 address. The router then has all it needs to figure out where to send the packet to. This is not possible across a native IPv6 backbone when BGP is advertising IPv4 NLRIs and the next-hop field must hold an IPv4 address. This will not be much good because the IPv4 address is not known to the IPv6 backbone network. One could perhaps generate an IPv4-compatible IPv6 address but this places an addressing and configuration burden on the provider who must now configure their PE routers with this limited addressing scheme. Ideally one would like to relax this constraint and allow BGP to advertise IPv4 prefixes with an IPv6 next-hop address. In addition to its non-VPN-centricity and tunnel agnosticism, the softwire mesh framework must accommodate the suite of client IPv4- over-backbone IPv6 scenarios. Wu, et al. Expires December 19, 2006 [Page 15] Internet-Draft Softwires Mesh Framework June 2006 +--------+ +--------+ | IPv4 | | IPv4 | | AF | | AF | | Access | | Access | | Island | | Island | +--------+ +--------+ | \ / | | \ / | | \ / | | X | | / \ | | / \ | | / \ | +--------+ +--------+ | AFBR | | AFBR | +--| IPv4/6 |---| IPv4/6 |--+ | +--------+ +--------+ | +-------+ | | +-------+ | IPv6 | | | | IPv6 | | AF | | IPv6 | | AF | | Access|-------| Transit Core |-------| Access| | Island| | | | Island| +-------+ | | +-------+ | +--------+ +--------+ | +--| AFBR |---| AFBR |--+ | IPv4/6 | | IPv4/6 | +--------+ +--------+ | \ / | | \ / | | \ / | | X | | / \ | | / \ | | / \ | +--------+ +--------+ | IPv4 | | IPv4 | | AF | | AF | | Access | | Access | | Island | | Island | +--------+ +--------+ Figure 2 IPv4-over-IPv6 Scenario Wu, et al. Expires December 19, 2006 [Page 16] Internet-Draft Softwires Mesh Framework June 2006 4. Reference Models This section a illustrates the softwire mesh and AFBR reference models and describes the entities of each. 4.1. Softwire Mesh Reference Model The reference model for the softwires mesh framework is illustrated in figure 3. | | | | | | | | | |<------------>| | | | | | |<---AF(i)---->|<----|<-----AF(i)--->| | Routing | SW_NHOP> | Routing | | | | | +-------+ +-------+ +-------+ +-------+ |AF(i) | | | (Single AF(j)) | | |AF)i) | |Access |------| AFBR |===(Transit Core)===| AFBR |------|Access | |Island | |AF(i,j)| |AF(i,j)| |Island | +-------+ +-------+ +-------+ +-------+ /|\ /|\ | | | [STH] | ---[SPH]---->SW Encap=======[SPH]==========>SW Decap---[SPH]---> [payload] [payload] [payload] Figure 3 Softwire Mesh Reference Model Softwires are established between dual-stack AF(i,j) AFBRs using softwire signaling. AF access island reachability and softwire next- hop information (SW_NHOP) is exchanged between AFBRs. AFBRs will also peer with routers in the AF access island networks to exchange AF(i) routing information. Packets composed of a payload and an IP header termed the SPH flow across the single AF transit core in softwires encapsulated with an AF(j)-based STH. 4.2. Entities of the Softwire Mesh Reference Model The entities of the reference model are: Single AF (j) transit core This is an IPv4 or IPv6 backbone network surrounded by a periphery of dual-stack AFBR routers. The transit core provides inter-access island connectivity across a mesh of softwires. Wu, et al. Expires December 19, 2006 [Page 17] Internet-Draft Softwires Mesh Framework June 2006 Note that single AF (j) access islands may also be attached to the single AF (j) transit core. Connectivity between single AF(j) access islands across the transit core can be accomplished using softwires or normal default routing functions depending on the wishes of the operator and routing configuration of the system. AF Access Islands Client access island networks can be single AF(i) or dual-stack AF(i,j) in makeup and rely on the transit core for connectivity to remote access island networks of the same AF. Routers inside an AF access island will run a routing protocol and subset of access island CE routers will peer with upstream AFBRs to exchange client AF (i) or AF (i,j) reachability information. Address Family Borders Routers (AFBR) These are dual-stack AF (i,j) routers positioned at the edge of the transit core. They will form a peering relationship with one or more CE routers located inside the AF acccess island for the purpose of exchanging AF access island reachability information. AFBR nodes will peer with each other (directly or via a route reflector) to exchange SW-encap sets, perform softwire signaling, advertise AF access island reachability information and SW-NHOP information. Softwire Signaling This involves first the local definition of SW-encap sets on each AFBR and second, the dynamic establishment of softwires in which the peering AFBRs will exchange their configured SW-encap sets. A SW- encap set contains tunnel header parameters, preferences and the expected payload types (e.g. IPv4) carried by the softwire(s). Clients IP AF payloads originating at an AF access island are encapsulated in the STH at the ingress AFBR, forwarded across the backbone, de-encapsulated at the egress AFBR and forwarded on to the destination. 4.3. ABFR Reference Model The reference model for a dual-stack, softwire-capable AFBR node is shown in figure 4. Wu, et al. Expires December 19, 2006 [Page 18] Internet-Draft Softwires Mesh Framework June 2006 +------------------------------->Remote AF(i,j) | AFBR Peers | | +-------------------------->AF(j) Transit | | Core Peers +------|----|-------------------------+ | | | | | \|/ \|/ | | +--------------+ +-------------+ | | | | | | | AF(i),AF(i,j) | |AF(i,j)Access | | | | Access <--|--|AF(j) Transit | | SW Tunnel |--|->Remote AF(i,j) Island | | Core | | Signaling | | AFBR Peers | | RIB(s) | | | | | | | | | | | +--------------+ +-------------+ | | /|\ \ /|\ | | | \ | | | | \ | | | | \ | | | | \ | | | | \ | | | \|/ _\| \|/ | | +----------+ +--------------+ | | | | | | | | | | | SW Tunnel | | AF Access<--|->| L3 FIB |<--->| Encap/Decap |<-|-->Single AF Island | | | | Forwarding | | Transit Core | | | | | | | +----------+ +--------------+ | | | +-------------------------------------+ Figure 4 Softwire AFBR Reference Model 4.4. Entities of the AFBR Reference Model The entities of the softwire AFBR reference model are: SW Signaling Module This module is responsible for exchanging SW-encap set(s) and other information with interested AFBR nodes for the purpose of establishing and managing inter-AFBR softwires. AF Access Island and Transit Core RIB(s) This entity represents the one or more routing information bases Wu, et al. Expires December 19, 2006 [Page 19] Internet-Draft Softwires Mesh Framework June 2006 (RIB) needed to store AF reachability information received over the AFBR’s multiple peering relationships. An AFBR will peer with one or more AF access island CE routers to exchange AF(i) or AF(i) and AF(j) prefixes and store those in an AF access island RIB. An AFBR will peer with remote AFBR nodes to exchange the same possible combination of AF access island prefixes (accompanied by SW-NH information) and store those in the same AF access island RIB. And finally the AFBR will peer with routers inside the transit core and store that information in a transit core RIB. AF L3 FIB(s) This entity represents the one or more forwarding information bases (FIB) computed from the RIB(s) and needed to forward the packets to and from the AF access islands and into and out of the softwire tunnels. SW Tunnel Encap/Decap and Forwarding This entity represents the softwire encapsulation and decapsulation processes performed at the ingress and egress AFBR respectively as well as the lookup and forwarding of the packet based on the STH. This is NOT how a specific implementation must look but rather illustrates the basic function blocks that run in the dual-stack, softwire-capable AFBR. 4.5. Comments on Single AF AFBR Reference Models This document describes a framework employing dual-stack AFBR nodes. Noting the cost and perceived complexity of running anything in dual- stack, one might ask is it possible to solve this problem using single-stack AFBR nodes. The answer is yes. One technique would be to make the AFBR a single-stack AF(j) node similar to the transit core routers. It then becomes up to a CE device located in the AF access island network to encapsulate/ de-encaspulate packets in a tunnel that can be forwarded across the single-stack AF(j) backbone composed of AFBR and core routers. This involves moving the dual-stack AF(i,j) processing into the AF access island networks. This processing might evolve manual configuration of inter-CE tunnels or inter-CE BGP peering to exchange client AF prefixes/next-hops. This may not be desirable on the part of the operators of those networks. We call this the dual-stack CE model. Another technique is to employ psuedowire (PW) control and encapsulations [RFC3985] as a means of tunneling AF access island Wu, et al. Expires December 19, 2006 [Page 20] Internet-Draft Softwires Mesh Framework June 2006 packets across the transit core. In this case the AFBR assumes the role of L2 PE and need only peer with transit core and other remote L2 PE vehicles. It will only forward packets based on L2 connection, L2 header or interface information. A CE router will attach to the L2 AFBR and exchange L2-encapsulated AF access island packets across L2 connections. We call this model the L2VPN model. These approaches circumvent the requirement for dual-stack functionality on the AFBR which can be viewed as an advantage. The disadvantage of the dual-stack CE model is added cost and complexity placed in the AF access island networks. The disadvantage of the L2VPN is limited scalability. Wu, et al. Expires December 19, 2006 [Page 21] Internet-Draft Softwires Mesh Framework June 2006 5. Softwire Signaling A mesh of inter-AFBR softwires spanning the single AF transit core must be in place before packets can flow between AF access island networks . Given N number of dual-stack AFBRs, it is possible to erect a softwire mesh by manually configuring a full mesh of point- to-point IP or label switch path (LSP) tunnels. This of course introduces the O(N^2) provisioning problem. A more scalable and provision-friendly approach is to establish the softwire mesh dynamically using some sort of signaling. Before deciding on an approach we make two quick observations: o reachability to particular AF access island prefixes is always through one or more egress AFBRs. In the BGP vernacular, this would be the BGP next_hop pointing to an egress PE. o egress AFBR knows exactly the composition of the SW-encap sets it is capable of supporting. It knows what tunnel encapsulation type(s) it can handle and the parameters (e.g. tunnel header fields) of those tunnel encapsulation types. If the egress AFBR supports more than one tunnel encapsulation type, then the egress AFBR's preference for using one over the other can be expressed. It also is aware of the IP AF payloads these tunnel encapsulations will bear and of course it knows its own IP address. With this in mind, we can envision a softwire signaling solution where each egress AFBR advises all interested ingress AFBRs of the following: . Upon receiving this information, the ingress AFBR knows how to reach the egress AFBR and what tunnels encapsulation types to apply if it needs to forward packets to prefixes emanating from that egress AFBR. 5.1. SW Encapsulation Sets A SW-encap set is composed of the following: o a type of payload (e.g. IPv4 or IPv6) that will be transported in the softwire. This exists so that the egress AFBR can optimize its processing (e.g. lookup) of the payload once it exits the softwire. o one or more tunnel encapsulation types and associated parameters that can be applied to the payload type. For example one encapsulation type might be GRE [RFC2784] and the parameters would be an ethertype and optionally a key value. Wu, et al. Expires December 19, 2006 [Page 22] Internet-Draft Softwires Mesh Framework June 2006 o a preference expressed by the egress AFBR to the multiple ingress AFBRs on which tunnel encapsulation type to apply to the specified payload. This would apply if the egress AFBR is capable of supporting and then advertised multiple tunnel encapsulation types for a particular payload. Basically the SW-encap set and AFBR IP address of the egress AFBR is what needs to be conveyed to all interested ingress AFBR nodes so that the softwire mesh can be built. 5.2. BGP An ideal choice for softwire signaling is MP-BGP [RFC2858]. First it supports the one-to-many signaling paradigm required by the egress AFBR to communicate softwire information to multiple ingress AFBRs. This can occur across a full mesh of BGP connections or route reflectors can be employed for improved scalability. Second BGP need only operate between softwire-capable AFBR nodes since these are the only devices that maintain softwire tunneling state. And finally BGP has proven to be quite extensible and so can be easily extended to carry softwire information between AFBRs. A new SAFI defined in [draft-nalawade-kapoor-tunnel-safi] and a new attribute for encoding SW-encap sets, [draft-nalawade-softwire-encap- attribute] are introduced to provide MP-BGP with the ability to dynamically establish a softwire mesh between AFBR nodes. [draft-nalawade-kapoor-tunnel-safi] describes the following: o new SAFI (= 64) encoded in the MP_REACH_NLRI attribute indicates that information pertaining to an IPv4 (AFI=1) or IPv6 (AFI=2) tunnel is encoded. We refer to the MP_REACH_NLRI attribute containing the tunnel SAFI as just the tunnel SAFI. o NLRI of the tunnel SAFI is encoded with a tunnel identifier and the IP address of the tunnel end-point which in this case is the IP address of the egress AFBR. The indentifier and/or the IP address will be indexed by subsequent prefix advertisements coupled with a SW-NHOP attribute value to associate reachability to an advertised prefix through that softwire. [draft-nalawade-softwire-encap-attribute] describes the following: o Payload AFI and SAFI. o Softwire encapsulation parameters defining the tunnel encapsulation types and preferences. The egress AFBR then will employ MP-BGP to distribute information as a means of signaling softwire setups to interested AFBR nodes. The softwire payload AFI/SAFI and the tunnel encapsulation attributes collectively form the SW-encap set. And the NLRI of the tunnel SAFI contains a tunnel identifier value and the tunnel end-point IP address which is the IP address of the egress AFBR. Note that this information should be confined to only participating autonomous systems so mechanisms to control the distribution of softwire information should be invoked as needed. Upon receiving the BGP tunnel SAFI advertisement, the ingress AFBR resolves the SW-encap set to exactly one encapsulation type to use when sending packets of the specified payload type to a destination advertised by the egress AFBR. This is based on first whether the AFBR is capable of supporting a particular encapsulation type and second on the order of preference. With respect to order of preference, it is desirable that the ingress AFBR attempt to honor the preference expressed by the egress AFBR. However it is possible to configure a policy on the ingress AFBR that overrides the preference received from the egress AFBR in the BGP tunnel SAFI update. 5.3. non-BGP Signaling Dynamic and static methods that do not employ MP-BGP and the BGP tunnel SAFI can be used to establish the mesh of inter-AFBR softwires. Existing point-to-point signaling protocols can establish discrete softwires between pair-wise AFBR nodes. For example if the transit core is based on MPLS, then the operator could configure a mesh of traffic engineered tunnel LSPs using RSVP-TE signaling [RFC3209] between the ingress and egress AFBR. The mesh of TE LSPs would constitute the softwire mesh. In the case where point-to-point signaling is used, it might be necessary to configure each softwire with an identifier which can be later referenced by a client AF prefix advertisement received at the ingress AFBR to indicate that the softwire leads to the set of client AF prefixes. Wu, et al. Expires December 19, 2006 [Page 24] Internet-Draft Softwires Mesh Framework June 2006 6. Softwire Routing and Tunnel Selection Once the softwire mesh is in place, it now becomes possible to forward packets over a particular softwire. The ingress AFBR will make this decision based on learned client AF access island reachability information and the corresponding SW-NHOP value pointing to a specific softwire to use. So essentially two things need to happen here: o egress AFBR nodes need to advertise client AF access island reachability to the set of interested ingress AFBRs o egress AFBR nodes need to identify a softwire to use to reach the advertised AF access island prefixes. The learned tunnel-to-use information will also include the IP address of the egress AFBR. 6.1. Advertising Client AF Access Island Reachability AFBR nodes maintain routing tables gleaned from directly connected AF access island networks. The prefixes maintained in these AF access island routing tables will be from different address families including IPv4, VPNv4, IPv6 and VPNv6. Therefore the logical choice on how to convey multi-AF reachability information between AFBR nodes is MP-BGP. Softwire routing will employ existing and proven mechanisms for advertising reachability between AFBR nodes. Table 1 below describes the possible access island AF/SAF maintained on the AFBR nodes and the reference describing the MP-BGP implementation: AF/SAF Reference ====== ================================ 1/1 (IPv4) [RFC2858] 2/1 (IPv6) [RFC2858] 1/128 (VPNv4) [RFC4364] 2/128 (VPNv6) [draft-ietf-l3vpn-bgp-ipv6] Table 1 AF Access Island References It should be noted that prefixes belonging to different AF/SAFs will be stored in different routing tables on the AFBR. In addition the particular AF/SAF combinations described here are completely separate from the AF of the transit core. Wu, et al. Expires December 19, 2006 [Page 25] Internet-Draft Softwires Mesh Framework June 2006 6.2. Tunnel Selection In conjunction with multi-AF reachability achieved through existing MP-BGP protocol machinery, some form of tunnel indirection must be peformed. In other words the egress AFBR must tell the ingress AFBRs that to reach a particular prefix across the transit core, the ingress AFBR must direct the the packets into a specific softwire. The notion of instructing a node to forward packets to a destination other than the default next_hop is referred to as tunnel indirection. Tunnel indirection generally applies in the following cases: o if the characteristics of an existing tunnel (i.e. softwire) change then the ingress AFBR must be advised that reachability to prefixes is now only possible through the changed tunnel. For example an egress AFBR employing L2TPv3 encapsulation may decide to alter its cookie value in the L2TPv3 header for security reasons. The egress AFBR transmits a BGP tunnel SAFI update containing a new SW-encap set with the new cookie value. In addition the egress AFBR must quickly inform the ingress AFBRs that advertised AF access island reachability is now supported through the updated L2TPv3-based softwire. o if there are multiple softwires to choose from. An egress AFBR could advertise two or more discrete SW-encap sets, each capable of carrying the same payload type(s). In this case the egress AFBR must inform the ingress AFBR what prefixes are reachable through which softwire. Mapping prefixes to specific tunnels can also be done manually but comes at a cost in operational complexity. 6.2.1. Softwire Next_Hop Tunnel indirection can be achieved by accompanying MP-BGP prefix updates with a pointer to a softwire leading to the advertised prefix. This pointer could be a value that indexes a table (located on the ingress AFBR) of referenceable softwires leading to the the advertising or egress AFBR. The pointer might also be complimented with an IP address which serves as the softwire end-point address configured on the egress AFBR. This IP address would also be used by the ingress AFBR as the STH when assembling and imposing the encapsulation headers on the client packet to be forwarded through the softwire that spans the transit core. The BGP Softwire Next Hop (SW-NHOP) [draft-nalawade-sw-nhop] attribute is a new attribute that serves this purpose. This attribute effectively functions as a softwire next_hop (SW_NHOP) in that it points to a previously configured softwire (on the ingress Wu, et al. Expires December 19, 2006 [Page 26] Internet-Draft Softwires Mesh Framework June 2006 AFBR) and provides an IP address that can serve as the STH in the softwire encapsulation. A prefix received by the ingress AFBR that contains a SW_NHOP (by virtue of the BGP SW-NH attribute) is being instructed to forward packets to that prefix through the referenced SW. Another use of this attribute is that it can supercede the next_hop value contained in the MP_REACH NLRI. Since the SW_NHOP attribute explicitly identifies the AFI/SAFI of its contained IP address, this means that the constraint of the matching AFI/SAFI between NLRI and next hop fields in an MP_REACH_NLRI can be circumvented. This will be quite useful when addressing the IPv4-over-IPv6 scenario. The SW_NHOP attribute links reachability to a softwire and the IP address at the end of the softwire which in this case is the IP address of the egress AFBR. This translates into a softwire encapsulation action performed by the ingress AFBR rather then just a forwarding action to a next hop router as is the usual case with routing. If prefixes packed up with SW_NHOP attribute arrive at an ingress AFBR and there is no active softwire then the prefixes are dropped since they are not reachable. If prefixes arrive without the SW_NHOP attribute or if this function has not been negotiated in the capabilities exchange, then normal next_hop forwarding should be performed. A situation may arise where an AF(i) prefix is reachable through a softwire and a normal next_hop address. It is possible that some form of load sharing could occur, where some packets are directed through the softwire next hop and others through the normal next hop. The implementation can choose to support this scenario or mandate the use of just a single method for expressing reachability and next hop information. In practice it is likely that the provider will only support a single form of transport between AFBR nodes. The use of the SW_NHOP attribute offers several advantages: o Egress AFBR can assign reachability to different prefix sets using different encapsulation schemes. For example one set of prefixes can be reached through a GRE tunnel and another might be reachable through an IPsec tunnel. o Decoupling of AF access island reachability and softwire signaling leads to more efficient MP-BGP processing. This is because MP-BGP prefix updates do not transport the corresponding SW-encap set(s). That is performed once per softwire setup by the BGP tunnel SAFI. The prefix updates only a carry a pointer indexing the softwire to Wu, et al. Expires December 19, 2006 [Page 27] Internet-Draft Softwires Mesh Framework June 2006 use. o Constraint of the of the NLRI and next-hop fields sharing the same AFI/SAFI in the MP_Reach_NLRI attribute is removed by encoding overriding next hop information in the SW_NHOP attribute. In summary, MP-BGP will advertise tuples between peering AFBR nodes as a means of binding reachability to a client AF prefix through a configured softwire. 6.2.2. Next_Hop Overlay Addressing Another form of tunnel indirection can be achieved by linking advertised MP-BGP prefix next_hop information to a tunnel end-point terminating in the egress AFBR. This is achieved by configuring an IP overlay address, called IP(overlay), on the egress AFBR that is part of the same AF as that of the advertised AF acccess island prefixes. The softwire mesh is dynamically built by extending the BGP tunnel SAFI to carry the following information: . When MP-BGP prefix updates arrive at the ingress AFBR, the next_hop will be resolved to the IP (overlay) address which in turn is bound to an encapsulation action based on the SW-encap set and AFBR IP address values. In this case the SW_NHOP attribute is not used and there is no additional information needed when MP-BGP prefixes updates are sent by egress AFBR nodes. However the operator must configure one extra IP (overlay) address per softwire and then advertise this information in an extended BGP tunnel SAFI update. 6.3. Comments on a BGP-free Core The term BGP-free core describes a scenario where the network is an autonomous system (AS), the edge routers are EBGP speakers, and the strategy is to keep the core routers free of external routes. The edge routers must distribute routes to each other, but not to the core routers. The requirement itself opens up the possibility to design the core network with a softwire mesh framework. The edge routers take on the role of AFBRs that exchange the external routes with each other. The external routes may or may not be of the same address family as the core network. The edge routers also signal the SW-encap set identifying each egress endpoint. Traffic for the Wu, et al. Expires December 19, 2006 [Page 28] Internet-Draft Softwires Mesh Framework June 2006 external routes are forwarded by encapsulating the packets with a tunnel header at the ingress. Wu, et al. Expires December 19, 2006 [Page 29] Internet-Draft Softwires Mesh Framework June 2006 7. Softwire Forwarding and Tunnel Encapsulations 7.1. Forwarding Forwarding of packets sourced from an AF access island onto a softwire originating in the ingress AFBR is composed of the following: o lookup of AF access island IP destination address (SPH) in the respective AF access island routing and forwarding table. o Encapsulation of the IP packet in the appropriate softwire transport header (STH). o Transmission of the softwire encapsulated packets across the single AF transit core based on the STH. When packets arrive at the egress AFBR the following actions are performed: o Disposition of the STH. o Lookup of the SPH in the corresponding AF acccess island routing and forwarding table. o Transmission of the native AF access island IP packet toward the respective downstream CE router. 7.2. Encapsulations The softwire mesh framework is designed to accommodate any form of IP tunnel encapsulation. Examples include [RFC2784], [RFC3931] and IP- in-IP [RFC2473]. MPLS encapsulation can also be accomodated as well. IPsec is a special case that will be covered in a separate document. Wu, et al. Expires December 19, 2006 [Page 30] Internet-Draft Softwires Mesh Framework June 2006 8. Softwire OAM and MIBs 8.1. OAM Softwires are essentially tunnels connecting routers. If they disappear or degrade in performance then connectivity through those tunnels will be impacted. There are several techniques available to monitor the status of the tunnel end-points (e.g. AFBRs) as well as the tunnels themselves. These techniques allow operations such as softwires path tracing, remote softwire end-point pinging and remote softwire end-point liveness failure detection. Examples of techniques applicable to softwire OAM include: o BGP/TCP timeouts between AFBRs o ICMP or LSP echo request and reply addressed to a particular AFBR o [draft-ietf-bfd-base] packet exchange between AFBR routers Another possibility for softwire OAM is to build something similar to the [RFC4378] or in other words creating and generating softwire echo request/reply packets. The echo request sent to a well-known UDP port would contain the egress AFBR IP address and the softwire identifier as the payload (similar to the MPLS forwarding equivalence class contained in the LSP echo request). The softwire echo packet would be encapsulated with the STH and forwarded across the same path (inband) as that of the softwire itself. This mechanism can also be automated to periodically verify remote softwires end-point reachability, with the loss of reachability being signaled to the softwires application on the local AFBR thus enabling suitable actions to be taken. Consideration must be given to the trade offs between scalability of such mechanisms verses time to detection of loss of endpoint reachability for such automated mechanisms. In general a framework for softwire OAM can for a large part be based on the [RFC4176] framework. 8.2. MIBs Specific MIBs do exist to manage elements of the softwire mesh framework. However there will be a need to either extend these MIBs or create new ones that reflect the functional elements that can be SNMP-managed within the softwire network. Wu, et al. Expires December 19, 2006 [Page 31] Internet-Draft Softwires Mesh Framework June 2006 9. Softwire Multicast A set of client IP AF access island networks that are connected to a provider's single AF transit core network may wish to run IP multicast applications. Extending IP multicast connectivity across the provider's single AF transit core network can be accomplished using a variety of techniques. One option is to extend client IP AF multicast up to the provider's AFBR and then tunnel the client IP AF multicast packets across the unicast softwire mesh. Tunneling IP multicast packets across inter- router unicast IP tunnels such as GRE has been performed for years. This is sub-optimal from the provider's perspective given that there is no replication done inside the transit core. A further hit in optimality will be incurred by the replication processing performed by the ingress AFBR, especially if there are many downstream AFBRs on the tree. The advantage is that it does work and the softwire mesh handles both unicast and multicast traffic. A second option is to leverage the multicast VPN work already defined and in fact implemented [draft-ietf-l3vpn-2547bis-mcast]. In this scenario the transit core implements native IP multicast or MPLS multipoint LSPs to establish multipoint distribution trees called provider multicast service instances (PMSI). The PMSI might use an IP tunnel encapsulation with a provider-only group address as one encapsulation or MPLS labels as another. Client AF access island multicast packets are encapsulated in PMSI headers at the ingress AFBR and then transmitted on the appropriate PMSI for delivery to leaf AFBRs. The PMSI headers are removed and the client AF multicast packet is sent on its way. It should be noted that PMSI establishment and encapsulation operates separately from softwire signaling and encapsulation. One could say they operate as "ships in the night". The advantage of the MVPN approach is that packet replication is performed in the transit core. The disadvantage is that the enabling client AF IP multicast means that client AF prefixes must be stored and processed in VPN routing tables on the AFBR which as noted earlier may not be something the provider wishes to do. It should also be pointed that the existing MVPN implementations and in fact the current [draft-ietf-l3vpn-2547bis-mcast] draft only refers to the IPv4 AF for both the client and backbone networks. This effort needs to be extended to support IPv6 AF. A third option is to push the client AF-to-backbone AF interface down to the CE. A simply way of realizing this would be to establish a mesh of point-to-point softwires between participating CE routers. This has scaling concerns similar to the aforemented AFBR-based Wu, et al. Expires December 19, 2006 [Page 32] Internet-Draft Softwires Mesh Framework June 2006 softwire mesh tunneling solution. Another technique specific to the IPv4-over-IPv6 scenario is outlined in [draft-ietf-softwire-4over6vpns]. An IPv6 group address is assigned to each VPN and the CE routers join the group to discover each and build inter-CE routing adjacencies. IPv4 multicast packets are encapsulated in an IPv6 group address derived from the IPv4-based source and group address information. The advantage of this approach in particular is that the AFBR only runs IPv6 and not a dual-stack. Wu, et al. Expires December 19, 2006 [Page 33] Internet-Draft Softwires Mesh Framework June 2006 10. Inter-AS Considerations [RFC4364] describes three methods for supporting L3VPN functions across inter-AS topologies. These methods can be leveraged to support softwire signaling, routing and encapsulation across the same topologies. 10.1. Option A: Back-to-Back AFBRs This option works seamlessly with the softwire mesh framework. Referring to figure 5 the peering AFBRs located in different automomous systems (AFBR2 and AFBR3) have one or more attachment circuits which are capable of forwarding AF(i) packets. AFBR1 and AFBR2 exchange client AF(i) prefixes and SW-NHOP information with each other. From the forwarding perspective beginning at AFBR1, packets are tunneled over softwire 1 that terminates at AFBR2 where the packets are de-encapsulated and sent as normal AF(i) IP packets over the attachment circuit to the AFBR3 in the other AS. The packet is then tunneled over softwire 2 to AFBR and so on. Softwire 1 +**********************+ AF(i) | | --AFBR1=(AS1 transit core)=AFBR2 island AF(j) | | | | | | AF(k) AF(i) AFBR3=(AS2 transit core)=AFBR4-- | | island +*************************+ Softwire 2 Figure 5 Option A Back-to-Back AFBRs A characterstic of option A is that the AF of each transit core network within each AS could be different. i.e. the first AS's core network can be AF(j) and the second AS's core network can be AF(k). 10.2. Option B: EBGP redistribution of AF(i) prefixes In this procedure, the AFBRs use MP-iBGP and MP-eBGP signalling between intra-AS and inter-AS AFBR peers to build a contiguous set of softwires that span multiple autonomous systems. The same MP-iBGP and MP-eBGP machinery is then used to redistribute AF(i) prefixes and SW- NHOP attributes that in turn builds the forwarding plane through this contiguous set of softwires. Wu, et al. Expires December 19, 2006 [Page 34] Internet-Draft Softwires Mesh Framework June 2006 o The packets at the ingress ASBR enter softwrite 1. o Softwire '1' terminates at the AFBR2. o Packets enter softwire 2 that is setup between the AFBR2 and AFBR3. o Softwire 2 terminates on AFBR3. o Packets are then de-encapsulated and forwarded over softwire 3 to AFBR4 and so on. Softwire 1 +**********************+ AF(i) | | --AFBR1=(AS1 transit core)=AFBR2---+ island H | Softwire 2 H | H _| H / AF(i) AFBR3=(AS2 transit core)=AFBR4-- | |island +*************************+ Softwire 3 Figure 6 Option B "C EBGP Distribution of AF(i) Prefixes To set up the softwires, softwire signalling exchanges SW-encaps sets between each pair peering AFBRs, including those AFBR peers located in separate autonomous systems (e.g. AFBR2 and AFBR3 in figure 6). In this option as well, the AFs of the core network within each AS need not be the same, i.e. AS1 transit core can be AF(j) whereas AS2 transit core can be AF(k). The inter-AS AFBRs of course need to be AF(i, j, k) aware, where i, j, k could be the same or different. 10.3. Option C: Multihop EBGP distribution of AF(i) prefixes In this procedure, AF(i) prefixes are redistributed by some designated AFBRs to the other AS with the next-hop unchanged, (i.e. the next-hops are not rewritten by the EBGP AFBR speaker). The inter-AS peering AFBRs need only to exchange host AF(j) routes of the AFBRs so that AFBRs in both the ASs have reachability to each other. The designated AFBRs also signal softwire SW-encap sets of each end- point without rewriting the next-hops. This facilitates the creation Wu, et al. Expires December 19, 2006 [Page 35] Internet-Draft Softwires Mesh Framework June 2006 of an end-to-end softwire from the ingress AFBR to the egress AFBR As illustrated in figure 7. Softwire +*************************************************+ | | | | | +==AFBR3-----+ | AF(i) | // . EBGP & softwire | --AFBR1=(AS1 transit core)=AFASBR1 . signaling | island H . | H . | H +==AFBR4 | H // | AF(i) AFASBR2=(AS2 transit core)=AFBR2-- island Figure 7 Option C Multihop eBGP distribution of AF(i) prefixes This procedure inherently assumes that both the AS transit cores run the same AF(j) network because of the requirement to redistribute reachability information of AFBRs across ASs. Wu, et al. Expires December 19, 2006 [Page 36] Internet-Draft Softwires Mesh Framework June 2006 11. Security Considerations Security for softwire signaling can be achieved using BGP/TCP MD5- keying. The softwire data plane can employ encryption of the data packets using Ipsec. This will be explained in a companion document. [RFC4111] outlines the L3VPN security framework which in many cases is directly applicable to the softwire mesh framework. Wu, et al. Expires December 19, 2006 [Page 37] Internet-Draft Softwires Mesh Framework June 2006 12. Acknowledgment David Ward, Eric Rosen, Chris Cassar, Ruchi Kapoor, Pranav Mehta, Mingwei Xu and Ke Xu provided useful input into this document. Wu, et al. Expires December 19, 2006 [Page 38] Internet-Draft Softwires Mesh Framework June 2006 13. References 13.1. Normative References [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, October 1994. [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- Edge (PWE3) Architecture", RFC 3985, March 2005. [RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4110, July 2005. [RFC4111] Fang, L., "Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4111, July 2005. [RFC4176] El Mghazli, Y., Nadeau, T., Boucadair, M., Chan, K., and A. Gonguet, "Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management", RFC 4176, October 2005. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. [RFC4378] Allan, D. and T. Nadeau, "A Framework for Multi-Protocol Label Switching (MPLS) Operations and Management (OAM)", RFC 4378, February 2006. Wu, et al. Expires December 19, 2006 [Page 39] Internet-Draft Softwires Mesh Framework June 2006 13.2. Informative References [draft-ietf-bfd-base] Katz, D. and D. Ward, "Bidirectional Forwarding Detection", draft-ietf-bfd-base-04 (work in progress), October 2005. [draft-ietf-l3vpn-2547bis-mcast] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-01 (work in progress), December 2005. [draft-ietf-l3vpn-bgp-ipv6] Clercq, J., "BGP-MPLS IP VPN extension for IPv6 VPN", draft-ietf-l3vpn-bgp-ipv6-07 (work in progress), August 2005. [draft-ietf-l3vpn-gre-ip-2547] Rekhter, Y., "Use of PE-PE GRE or IP in BGP/MPLS IP Virtual Private Networks", draft-ietf-l3vpn-gre-ip-2547-05 (work in progress), August 2005. [draft-ietf-softwire-problem-statement] Li, X., "Softwire Problem Statement", draft-ietf-softwire-problem-statement-00 (work in progress), December 2005. [draft-nalawade-kapoor-tunnel-safi] Nalawade, G., "Tunnel SAFI", draft-nalawade-kapoor-tunnel-safi-04 (work in progress), October 2005. [draft-ietf-softwire-4over6vpns] Shephard, G., "IPv4 unicast/multicast VPNs over an IPv6 core", draft-ietf-softwire-4over6vpns-00 (work in progress), June 2006. [draft-nalawade-softwire-encap-attribute] Nalawade, G., "BGP Softwire Encapsulation Attribute", draft-nalawade-softwire-encap-attribute-00 (work in progress), June 2006. [draft-nalawade-sw-nhop] Nalawade, G., "BGP Softwire Next Hop Attribute", draft-nalawade-sw-nhop-00, (work in progress), June 2006. Wu, et al. Expires December 19, 2006 [Page 40] Internet-Draft Softwires Mesh Framework June 2006 Authors' Addresses Jianping Wu Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6278-5983 Email: jianping@cernet.edu.cn Yong Cui Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6278-5822 Email: yong@csnet1.cs.tsinghua.edu.cn Xing Li Tsinghua University Department of Electronic Engineering, Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6278-5983 Email: xing@cernet.edu.cn Chris Metz Cisco Systems, Inc. 3700 Cisco Way San Jose, Ca. 95134 American Email: chmetz@cisco.com Wu, et al. Expires December 19, 2006 [Page 41] Internet-Draft Softwires Mesh Framework June 2006 Gargi Nalawade Cisco Systems, Inc. 3700 Cisco Way San Jose, Ca. 95134 American Email: qarqi@cisco.com Simon Barber Cisco Systems, Inc. 250 Longwater Avenue Reading, ENGLAND, RG2 6GB United Kingdom Email: sbarber@cisco.com Pradosh Mohapatra Cisco Systems, Inc. 3700 Cisco Way San Jose, Ca. 95134 American Email: pmohapat@cisco.com Wu, et al. Expires December 19, 2006 [Page 42] Internet-Draft Softwires Mesh Framework June 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Wu, et al. Expires December 19, 2006 [Page 43]