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 <SW ID:SW-NHOP address>. 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.
| | | |
| | | |
| |<------<SW Signaling>------>| |
| | | |
|<---AF(i)---->|<----<BGP: AF(i)prefixes,-->|<-----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
AFBRs 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: <AFBR IP address, SW-encap sets>. 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 <Tunnel SAFI:
Wu, et al. Expires December 19, 2006 [Page 23]
Internet-Draft Softwires Mesh Framework June 2006
SW-encap sets, Tunnel ID:Tunnen End-Point IP address> 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 <client AF prefixes, SW-NHOP>
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: <IP (overlay), SW-encap
sets, Tunnel ID:Tunnel End-Point IP address>.
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]