Network Working Group J. Wu
Internet Draft Y. Cui
Expiration Date: April 2007 X. Li
Tsinghua University
C. Metz
E. Rosen
S. Barber
P. Mohapatra
J. Scudder
Cisco Systems, Inc.
October 2006
Softwire Mesh Problem Framework
draft-wu-softwire-mesh-framework-01.txt
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.
Wu, et al. [Page 1]
Internet Draft draft-wu-softwire-mesh-framework-01.txt October 2006
Abstract
The Softwires Mesh Problem identifies a requirement for a
generalized, network-based client IPvX-over-backbone IPvY solution,
where for the case where X=4 and Y=6, as well as the case where X=6
and Y=4. BGP is used to distribute the routing information needed to
ensure connectivity among the client networks. Forwarding between
client networks is done by means of IP or MPLS tunnels, known as
"softwires". The solution is largely composed of existing
technology, in some cases with minor modifications. This framework
describes the overall solution, how the components of the solution
fit together, and specifies those areas in which new or modified
technology must be developed.
Table of Contents
1 Specification of requirements ...................... 3
2 Introduction ....................................... 3
3 Terminology ........................................ 6
4 Scenarios of Interest .............................. 8
4.1 IPv6-over-IPv4 Scenario ............................ 8
4.2 IPv4-over-IPv6 Scenario ............................ 10
5 Reference Models ................................... 12
5.1 Softwire Mesh Reference Model ...................... 12
5.2 Entities of the Softwire Mesh Reference Model ...... 13
5.3 ABFR Reference Model ............................... 14
5.4 Entities of the AFBR Reference Model ............... 15
5.5 Comments on Single AF AFBR Reference Models ........ 16
6 Selecting the Softwire Tunneling Mechanisms ........ 17
7 Softwire Signaling ................................. 18
8 Distribution of Inter-AFBR Routing Information ..... 19
9 Choosing to Forward Through a Softwire ............. 21
10 Selecting a Tunneling Technology ................... 21
11 Selecting the Softwire for a Given Packet .......... 22
12 Softwire OAM and MIBs .............................. 23
12.1 OAM ................................................ 23
12.2 MIBs ............................................... 24
13 Softwire Multicast ................................. 24
14 Inter-AS Considerations ............................ 25
15 Security Considerations ............................ 25
16 Acknowledgments .................................... 25
17 References ......................................... 26
18 Full Copyright Statement ........................... 29
19 Intellectual Property .............................. 29
Wu, et al. [Page 2]
Internet Draft draft-wu-softwire-mesh-framework-01.txt October 2006
1. Specification of requirements
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].
2. Introduction
The routing information in any IP backbone network can be thought of
as being in one of two categories: "internal routing information" and
"external routing information". The internal routing information
consists of routes to the nodes that belong to the backbone, and to
the interfaces of those nodes. External routing information consists
of routes to destinations beyond the backbone, especially
destinations to which the backbone is not directly attached. In
general, BGP is used to distribute external routing information, and
an IGP (such as OSPF or IS-IS) is used to distribute internal routing
information.
Often an IP backbone will provide transit routing services for
packets that originate outside the backbone, and that have
destinations that are outside of the backbone. These packets enter
the backbone at one of its "edge routers". The are routed through
the backbone to another edge router, after which they leave the
backbone and continue on their way. The term "ingress" refers to the
router at which a packet entered the backbone, and the term "egress"
refers to the router at which it leaves the backbone.
When a packet's destination is outside the backbone, the routing
information which is needed within the backbone in order to route the
packet to the proper egress is, by definition, external routing
information.
Traditionally, the external routing information has been made known
to all the routers in the backbone, not just to the edge routers
(i.e., to the ingress and egress points). That is, the external
routing information has traditionally been distributed by BGP to all
the backbone nodes. This allows each one of the interior backbone
nodes to look up the packet's destination address and route it
towards the egress point. This is known as "native forwarding": the
interior nodes look into each packet's header in order to match the
information in the header with the external routing information.
It is, however, possible to provide transit services without
requiring that all the backbone routers have the external routing
information. By virtue of the way BGP works, each ingress router
already knows the egress router for a given external route. The
Wu, et al. [Page 3]
Internet Draft draft-wu-softwire-mesh-framework-01.txt October 2006
ingress router can therefore "tunnel" the packet directly to the
egress router. "Tunneling the packet" means putting on some sort of
encapsulation header which will force the interior routers to forward
the packet to the egress router. Since the address of the egress
router is part of the internal routing information of the backbone,
the interior routers then to not need to know the external routing
information. Of course, before the packet could leave the egress, it
would have to be decapsulated. This is known as "tunneled
forwarding": the interior nodes do not look into the original header
of the packet, but only into the encapsulation header.
This type of scenario is sometimes known as a "BGP-free core".
That's something of a misnomer, though, since the crucial aspect of
this scenario is not that the interior nodes don't run BGP, but that
they don't maintain the external routing information.
In recent years, we have seen this scenario deployed to support VPN
services, as specified in [RFC4364]. An edge router maintains
multiple independent routing/addressing spaces, one for each VPN to
which it interfaces. However, the routing information for the VPNs
is not maintained by the interior routers. In most of these
scenarios, MPLS is used as the encapsulation mechanism for getting
the packets from ingress to egress. There are some deployments in
which an IP-based encapsulation, such as L2TPv3 [RFC3931] or GRE
[RFC2784] is used.
This same technique can also be useful when the external routing
information consists not of VPN routes, but of "ordinary" Internet
routes. It can be used any time it is desired to keep external
routing information out of a backbone's interior nodes, or in fact
any time it is desired for any reason to avoid the native forwarding
of certain kinds of packets.
This framework focuses on two such scenarios.
1. In this scenario, the backbone's interior nodes support only
IPv6. This means that they do not maintain IPv4 routes at all,
and perhaps cannot even parse IPv4 packet headers. Yet it is
desired to use such a backbone to provide transit services for
IPv4 packets. Therefore tunneled forwarding of IPv4 packets is
required. Of course, the edge nodes must have the IPv4 routes,
but the ingress must perform an encapsulation in order to get
an IPv4 packet forwarded to the egress.
2. This scenario is the reverse of scenario 1, i.e., the
backbone's interior nodes support only IPv4, but it is desired
to use the backbone for IPv6 transit.
Wu, et al. [Page 4]
Internet Draft draft-wu-softwire-mesh-framework-01.txt October 2006
In these scenarios, a backbone whose interior nodes support only one
of the two address families is required to provide transit services
for the other. The backbone's edge routers must, of course, support
both address families. We use the term "Address Family Border
Router" (AFBR) to refer to these edge routers. The tunnels that are
used for forwarding are referred to as "softwires".
It is possible to address these scenarios via a large variety of
tunneling technologies. Softwires will not mandate a single
tunneling technology. In any given deployment, the choice of
tunneling technology is a matter of policy. The framework
accommodates at least the use of MPLS ([RFC3031], [RFC3032]) (LDP-
based [RFC3036] or RSVP-TE-based [RFC3209]), L2TPv3 [RFC3931], GRE
[RFC2784], and IP-in-IP. The framework will also accommodate the use
of IPsec tunneling, when that is necessary in order to meet security
requirements.
It is expected that in many deployments, the choice of tunneling
technology will be made by a simple expression of policy, such as
"always use LDP-based MPLS", or "always use L2TPv3".
However, other deployments may have a mixture of routers, some of
which support, say, both GRE and L2TPv3, but others of which support
only one of those techniques. It is desirable therefore to allow the
network administration to create a small set of classes, and to
configure each AFBR to be a member of one or more of these classes.
Then the routers can advertise their class memberships to each other,
and the encapsulation policies can be expressed as, e.g., "use L2TPv3
to talk to routers in class X, use GRE to talk to routers in class
Y". To support such policies, it is necessary for the AFBRs to be
able to advertise their class memberships, and Softwires will specify
a standard way of doing this.
Policy may also require a certain class of traffic to receive a
certain quality of service, and this may impact the choice of tunnel
and/or tunneling technology used for packets in that class. This
should be accommodated by the Softwires framework.
The use of tunneled forwarding often requires that some sort of
signaling protocol be used to set up and/or maintain the tunnels.
Many of the tunneling technologies accommodated by the Softwires
framework already have their own signaling protocols. However, some
do not, and in some cases the standard signaling protocol for a
particular tunneling technology may not be appropriate, for one or
another reason, in the scenarios of interest. In such cases (and in
such cases only), new signaling methodologies will need to be defined
and standardized.
Wu, et al. [Page 5]
Internet Draft draft-wu-softwire-mesh-framework-01.txt October 2006
In this framework, the softwires do not form an overlay topology
which is visible to routing; routing adjacencies are not maintained
over the softwires, and routing control packets are not sent through
the softwires. Routing adjacencies among backbone nodes (including
the edge nodes) are maintained via the native technology of the
backbone.
There is already a standard routing method for distributing external
routing information among AFBRs, namely BGP. However, in the
scenarios of interest, we may be using IPv6-based BGP sessions to
pass IPv4 routing information, and we may be using IPv4-based BGP
sessions to pass IPv6 routing information. Furthermore, when IPv4
traffic is to be tunneled over an IPv6 backbone, it is desirable to
encode the "BGP next hop" for an IPv4 route as an IPv6 address, and
vice versa. There are existing methods for encoding an IPv4 address
as the next hop for an IPv6 route, but a method for encoding an IPv6
address as the next hop for an IPv4 route needs to be specified and
standardized.
3. Terminology
The following terminology will used in this document.
- Address Family (AF): IPv4 or IPv6.
- AF(c), AF(b): address families c and b, generally used when c=4
and b=6 or when c=6 and b=4, but it's not important to say which
is which.
AF(c) is generally used to indicate the address family of the
client networks.
AF(b) is generally used to indicate the address family of the
backbone (transit core) network.
- AF(c,b): 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, belonging to the backbone network, 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(c)
reachability information and encapsulates/decapsulates customer
Wu, et al. [Page 6]
Internet Draft draft-wu-softwire-mesh-framework-01.txt October 2006
packets in softwire transport headers.
- Customer Edge (CE) Router
A router located inside a client network that peers one or more
AFBRs.
- Client AF Prefixes
AF(c) or (if the client is dual stack) AF(b) prefixes originating
inside an AF client network.
- Single AF Transit Core
A single AF(b) transit core composed of IPv4 or IPv6 core routers
surrounded by a periphery of dual stack AF (b,c) AFBRs. The
transit core forward packets with IP AF(b) headers or labels
derived from an IP AF(b) control plane.
- Unicast Softwire (SW), or Softwire
A tunnel across the backbone network, connecting one or more
ingress AFBRs to a single egress AFBR.
A softwire corresponds to an encapsulation header in the native
AF of the backbone network, and is used to carry client packets
from one AFBR to another.
+ 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.
Wu, et al. [Page 7]
Internet Draft draft-wu-softwire-mesh-framework-01.txt October 2006
4. Scenarios of Interest
4.1. IPv6-over-IPv4 Scenario
In this scenario, the client networks run IPv6 but the backbone
network runs IPv4. This is illustrated in Figure 1.
Wu, et al. [Page 8]
Internet Draft draft-wu-softwire-mesh-framework-01.txt October 2006
+--------+ +--------+
| IPv6 | | IPv6 |
| Client | | Client |
| Network| | Network|
+--------+ +--------+
| \ / |
| \ / |
| \ / |
| X |
| / \ |
| / \ |
| / \ |
+--------+ +--------+
| AFBR | | AFBR |
+--| IPv4/6 |---| IPv4/6 |--+
| +--------+ +--------+ |
+--------+ | | +--------+
| IPv4 | | | | IPv4 |
| Client | | | | Client |
| Network|------| IPv4 |-------| Network|
+--------+ | | +--------+
| |
| +--------+ +--------+ |
+--| AFBR |---| AFBR |--+
| IPv4/6 | | IPv4/6 |
+--------+ +--------+
| \ / |
| \ / |
| \ / |
| X |
| / \ |
| / \ |
| / \ |
+--------+ +--------+
| IPv6 | | IPv6 |
| Client | | Client |
| Network| | Network|
+--------+ +--------+
Figure 1 IPv6-over-IPv4 Scenario
The IPv4 transit core may or may not run MPLS. If it does, MPLS may
be used as part of the solution.
While Figure 1 does not show any "backdoor" connections among the
Wu, et al. [Page 9]
Internet Draft draft-wu-softwire-mesh-framework-01.txt October 2006
client networks, this framework assumes that there will be such
connections. That is, there is no assumption that the only path
between two client networks is via the pictured transit core network.
Hence the routing solution must be robust in any kind of topology.
Many mechanisms for providing IPv6 connectivity across IPv4 networks
have been devised over the past ten years. A number of different
tunneling mechanisms have been used, some provisioned manually,
others based on special addressing. More recently, L3VPN techniques
from [RFC4364] have been extended to provide IPv6 connectivity, using
MPLS in the AFBRs and optionally in the backbone [draft-ooms-v6ops-
bgp-tunnel]. The solution described in this framework can be thought
of as a superset of [draft-ooms-v6ops-bgp-tunnel], with a more
generalized scheme for choosing the tunneling (softwire) technology.
In this framework, MPLS is allowed, but not required, even at the
AFBRs. As in [draft-ooms-v6ops-bgp-tunnel}, there is no manual
provisioning of tunnels, and no special addressing is required.
4.2. IPv4-over-IPv6 Scenario
In this scenario, the client networks run IPv4 but the backbone
network runs IPv6. This is illustrated in Figure 2.
Wu, et al. [Page 10]
Internet Draft draft-wu-softwire-mesh-framework-01.txt October 2006
+--------+ +--------+
| IPv4 | | IPv4 |
| Client | | Client |
| Network| | Network|
+--------+ +--------+
| \ / |
| \ / |
| \ / |
| X |
| / \ |
| / \ |
| / \ |
+--------+ +--------+
| AFBR | | AFBR |
+--| IPv4/6 |---| IPv4/6 |--+
| +--------+ +--------+ |
+--------+ | | +--------+
| IPv6 | | | | IPv6 |
| Client | | | | Client |
| Network|------| IPv6 |-------| Network|
+--------+ | | +--------+
| |
| +--------+ +--------+ |
+--| AFBR |---| AFBR |--+
| IPv4/6 | | IPv4/6 |
+--------+ +--------+
| \ / |
| \ / |
| \ / |
| X |
| / \ |
| / \ |
| / \ |
+--------+ +--------+
| IPv4 | | IPv4 |
| Client | | Client |
| Network| | Network|
+--------+ +--------+
Figure 2 IPv4-over-IPv6 Scenario
While Figure 2 does not show any "backdoor" connections among the
client networks, this framework assumes that there will be such
connections. That is, there is no assumption the only path between
two client networks is via the pictured transit core network. Hence
Wu, et al. [Page 11]
Internet Draft draft-wu-softwire-mesh-framework-01.txt October 2006
the routing solution must be robust in any kind of topology.
While the issue of IPv6-over-IPv4 has received considerable attention
in the past, the scenario of IPv4-over-IPv6 has not. Yet it is a
significant emerging requirement, as a number of service providers
are building IPv6 backbone networks and do not wish to provide native
IPv4 support in their core routers. These service providers have a
large legacy of IPv4 networks and applications that need to operate
across their IPv6 backbone. Solutions for this do not exist yet
because it had always been assumed that the backbone networks of the
foreseeable future would be dual stack.
5. Reference Models
This section illustrates the softwire mesh and AFBR reference models
and describes the entities of each.
5.1. Softwire Mesh Reference Model
The reference model for the softwires mesh framework is illustrated
in figure 3.
| | | |
| | | |
| |<------<SW Signaling>------>| |
| | | |
|<---AF(c)---->|<----<BGP: AF(c)prefixes,-->|<-----AF(c)--->|
| Routing | Next HOP> | Routing |
| | | |
+-------+ +-------+ +-------+ +-------+
|AF(c) | | | (Single AF(b)) | | |AF(c) |
|Client |------| AFBR |===(Transit Core)===| AFBR |------|Client |
|Network| |AF(c,b)| |AF(c,b)| |Network|
+-------+ +-------+ +-------+ +-------+
/|\ /|\
| |
| [STH] |
---[SPH]---->SW Encap=======[SPH]==========>SW Decap---[SPH]--->
[payload] [payload] [payload]
Figure 3 Softwire Mesh Reference Model
Softwires are established between dual-stack AF(c,b) AFBRs using
softwire signaling. Client network reachability and BGP next-hop
information is exchanged between AFBRs. Note that the remote
Wu, et al. [Page 12]
Internet Draft draft-wu-softwire-mesh-framework-01.txt October 2006
endpoint of the softwire used to carry a particular packet will be
the BGP next hop for that packet. AFBRs will also peer with routers
in the client networks to exchange AF(c) 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(b)-based STH.
Note that this reference model is no different than the reference
model one could give for any case of tunneling through a "BGP-free
core".
5.2. Entities of the Softwire Mesh Reference Model
The entities of the reference model are:
- AF(b)-only transit core (backbone)
This is an IPv4 or IPv6 backbone network surrounded by a
periphery of dual-stack AFBR routers.
Note that AF(b)-only client networks may also be attached to the
AF(b)-only transit core. Connectivity between AF(b)-only client
networks 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.
How this is done is beyond the scope of the current document.
- AF(c)-only or AF(c,b) Client Networks
Client networks can be AF(c)-only or dual-stack AF(c,b). In
either case, they rely on the transit core for connectivity to
other client networks that with which they have an AF in common.
Each client network must have at least one router which peers
with an AFBR to exchange routing information.
- Address Family Border Routers (AFBR)
These are dual-stack AF (c,b) routers positioned at the edge of
the transit core. They will form a peering relationship with one
or more client network routers for the purpose of exchanging
client network reachability information. AFBR nodes exchange
routing information with each other (including the AF(c) routing
information) and engage in any signaling necessary to set up the
needed set of softwires.
Wu, et al. [Page 13]
Internet Draft draft-wu-softwire-mesh-framework-01.txt October 2006
- Softwire Signaling
This is the signaling needed to set up the softwires, if any.
What if any signaling is needed depends on the particular type of
tunneling technology used to instantiate the softwires.
Clients IP AF payloads originating at an client network 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.
5.3. ABFR Reference Model
The reference model for a dual-stack, softwire-capable AFBR node is
shown in figure 4.
Wu, et al. [Page 14]
Internet Draft draft-wu-softwire-mesh-framework-01.txt October 2006
+------------------------------->Remote AF(c,b)
| AFBR Peers
|
| +-------------------------->AF(b) Transit
| | Core Peers
+------|----|-------------------------+
| | | |
| \|/ \|/ |
| +--------------+ +-------------+ |
| | | | | |
AF(c),AF(c,b) | |AF(c,b)Access | | | |
Access <--|--|AF(b) Transit | | SW Tunnel |--|->Remote AF(c,b)
| | Core | | Signaling | | AFBR Peers
| | RIB(s) | | | |
| | | | | |
| +--------------+ +-------------+ |
| /|\ \ /|\ |
| | \ | |
| | \ | |
| | \ | |
| | \ | |
| | \ | |
| \|/ _\| \|/ |
| +----------+ +--------------+ |
| | | | | |
| | | | SW Tunnel | |
AF Access<--|->| L3 FIB |<--->| Encap/Decap |<-|-->Single AF
| | | | Forwarding | | Transit Core
| | | | | |
| +----------+ +--------------+ |
| |
+-------------------------------------+
Figure 4 Softwire AFBR Reference Model
5.4. Entities of the AFBR Reference Model
The entities of the softwire AFBR reference model are:
- SW Signaling Module
This module is responsible for engaging in whatever signaling, if
any, may be necessary in order to set up and maintain the inter-
AFBR softwires.
Wu, et al. [Page 15]
Internet Draft draft-wu-softwire-mesh-framework-01.txt October 2006
- AF Routing Information Base (RIB)
This entity represents the one or more routing information bases
(RIB) needed to store AF reachability information received over
the AFBR's multiple peering relationships.
- AF Forwarding Information Base (FIB)
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 client networks 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.
5.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(b) node
similar to the transit core routers. It then becomes up to the
client network edge routers to (a) run in dual stack mode, and (b)
set up and maintain softwires to all other client edge routers.
However, this technique would not meet an important requirement,
viz., that the service provider be able to offer AF(c) transit
services over an AF(b) core, without requiring any change in the
equipment of the client network itself.
Another technique is to employ psuedowire (PW) control and
encapsulations [RFC3985] as a means of tunneling client network
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 client network packets across L2
Wu, et al. [Page 16]
Internet Draft draft-wu-softwire-mesh-framework-01.txt October 2006
connections. In essence, the transit core offers an L2VPN service to
the client networks. However, providing an L2VPN service is
certainly no simpler for an AFBR than running dual stacks, and the
disadvantages of using L2 technology to interconnect arbitrary
collections of client networks are well known.
6. Selecting the Softwire Tunneling Mechanisms
The Softwire Mesh Problem framework allows the softwires to be
instantiated by a large number of tunneling technologies.
The choice of tunneling technology is a matter of policy configured
at the ingress AFBR.
It is envisioned that in most cases, the policy will be a very simple
one, and will be the same at all the AFBRs of a given transit core.
E.g., "always used LDP-based MPLS", or "always use L2TPv3".
However, other deployments may have a mixture of routers, some of
which support, say, both GRE and L2TPv3, but others of which support
only one of those techniques. It is desirable therefore to allow the
network administration to create a small set of classes, and to
configure each AFBR to be a member of one or more of these classes.
Then the routers can advertise their class memberships to each other,
and the encapsulation policies can be expressed as, e.g., "use L2TPv3
to talk to routers in class X, use GRE to talk to routers in class
Y". To support such policies, it is necessary for the AFBRs to be
able to advertise their class memberships. [draft-pmohapat-idr-
info-safi] specifies a way in which an AFBR may advertise, to other
AFBRS, various characteristics which may be relevant to the polcy
(e.g., "I belong to class Y"). In many cases, these characteristics
can be represented by arbitrarily selected communities or extended
communities, and the policies at the ingress can be expressed in
terms of these classes (i.e., communities).
Policy may also require a certain class of traffic to receive a
certain quality of service, and this may impact the choice of tunnel
and/or tunneling technology used for packets in that class.
Wu, et al. [Page 17]
Internet Draft draft-wu-softwire-mesh-framework-01.txt October 2006
7. Softwire Signaling
A mesh of inter-AFBR softwires spanning the single AF transit core
must be in place before packets can flow between client networks.
Given N 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. Manual configuration of point-to-point tunnels
is not considered part of this framework.
Because the transit core is providing layer 3 transit services,
point-to-point tunnels are not required by this framework;
multipoint-to-point tunnels are all that is needed. In a
multipoint-to-point tunnel, when a packet emerges from the tunnel
there is no way to tell which router put the packet into the tunnel.
This models the native IP forwarding paradigm, wherein the egress
router cannot determine a given packet's ingress router. Of course,
point-to-point tunnels might be required for some reason which goes
beyond the basic Softwire requirements. E.g., QoS or security
considerations might require the use of point-to-point tunnels. So
point-to-point tunnels are allowed, but not required, by this
framework.
If it is desired to use a particular tunneling technology for the
softwires, and if that technology has its own "native" signaling
methodology, the presumption is that the native signaling will be
used. This would certainly apply to MPLS-based softwires, where LDP
or RSVP-TE would be used. A softwire based on IPsec would use
standard IKE/IPsec signaling, as that is necessary in order to
guarantee the softwire's security properties.
A Softwire based on GRE might or might not require signaling,
depending on whether various optional GRE header fields are to be
used. GRE does not have any "native" signaling, so for those cases,
a signaling procedure needs to be developed to support Softwires.
Another possible softwire technology is L2TPv3. While L2TPv3 does
have its own native signaling, that signaling sets up point-to-point
tunnels. For the purpose of softwires, it is better to use L2TPv3 in
a multipoint-to-point mode, and this requires a different kind of
signaling.
The signaling to be used for GRE and L2TPv3 to cover these scenarios
is BGP-based, and is described in [draft-pmohapat-idr-info-safi].
It is desirable for all necessary softwires to be fully set up before
the arrival of any packets which need to go through the softwires.
That is, the softwires should be "always on". From the perspective
Wu, et al. [Page 18]
Internet Draft draft-wu-softwire-mesh-framework-01.txt October 2006
of any particular AFBR, the softwire endpoints are always BGP next
hops of routes which the AFBR has installed. This suggests that any
necessary softwire signaling should be either be done as part of
normal system startup (as would happen, e.g., with LDP-based MPLS),
or else should be triggered by the reception of BGP routing
information (such as is described in [draft-pmohapat-idr-info-safi]);
it is also helpful if distribution of the routing information that
serves as the trigger is prioritized.
8. Distribution of Inter-AFBR Routing Information
AFBRs peer with routers in the client networks to exchange routing
information for the AF(c) family.
AFBRs use BGP to distribute the AF(c) routing information to each
other. This can be done by an AFBR-AFBR mesh of IBGP sessions, but
more likely is done through a BGP Route Reflector, i.e., where each
AFBR has an IBGP session to one or two Route Reflectors, rather than
to other AFBRs.
The BGP sessions between the AFBRs, or between the AFBRs and the
Route Reflector, will run on top of the AF(b) address family. That
is, if the transit core supports only IPv6, the IBGP sessions used to
distribute IPv4 routing information from the client networks will run
over IPv6; if the transit core supports only IPv4, the IBGP sessions
used to distribute IPv6 routing information from the client networks
will run over IPv4. The BGP sessions thus use the native networking
layer of the core; BGP messages are NOT tunneled through softwires or
through any other mechanism.
In BGP, a routing update associates an address prefix (or more
generally, "Network Layer Reachability Information", or NLRI) with
the address of a "BGP Next Hop" (NH). The NLRI is associated with a
particular address family. The NH address is also associated with a
particular address family, which may be the same as or different than
the address family associated with the NLRI. Generally the NH
address belongs to the address family that is used to communicate
with the BGP speaker to whom the NH address belongs.
Since routing updates which contain information about AF(c) address
prefixes are carried over BGP sessions that use AF(b) transport, and
since the BGP messages are not tunneled, a BGP update providing
information about an AF(c) address prefix will need to specify a next
hop address in the AF(b) family.
Due to a variety of historical circumstances, when the NLRI and the
NH in a given BGP update are of different address families, it is not
Wu, et al. [Page 19]
Internet Draft draft-wu-softwire-mesh-framework-01.txt October 2006
always obvious how the NH should be encoded. There is a different
encoding procedure for each pair of address families.
In the case where the NLRI is in the IPv6 address family, and the NH
is in the IPv4 address family, [draft-ooms-v6ops-bgp-tunnel] explains
how to encode the NH.
In the case where the NLRI is in the IPv4 address family, and the NH
is in the IPv6 address family, [draft-lefaucheur-idr-v4nlri-v6nh]
explains how to encode the NH.
If a BGP speaker sends an update for an NLRI in the AF(c) family, and
the update is being sent over a BGP session that is running on top of
the AF(b) network layer, and the BGP speaker is advertising itself as
the NH for that NLRI, then the BGP speaker MUST, unless explicitly
overridden by policy, specify the NH address in the AF(b) family.
The address family of the NH MUST not be changed by a Route
Reflector.
In some cases (e.g., when [draft-lefaucheur-idr-v4nlri-v6nh] is
used), one cannot follow this rule unless one's BGP peers have
advertised a particular BGP capability. This leads to the following
softwires deployment restriction: if a BGP Capability is defined for
the case in which an AF(c) NLRI has an AF(b) NH, all the AFBRs in a
given transit core MUST advertise that capability.
If an AFBR expects to get packets through a softwire, the NH
addresses that it advertises must be valid "remote endpoint
addresses" of the softwire.
In [draft-ooms-v6ops-bgp-tunnel], IPv6 routing information is
distributed using the labeled IPv6 address family. This allows the
egress AFBR to associate an MPLS label with each IPv6 address prefix.
If an ingress AFBR forwards packets through a softwire than can carry
MPLS packets, each data packet can carry the MPLS label corresponding
to the IPv6 route that it matched. This may be useful at the egress
AFBR, for demultiplexing and/or enhanced performance. It is also
possible to do the same for the IPv4 address family, i.e. to use the
labeled IPv4 address family instead of the IPv4 address family. The
use of the labeled IP address families in this manner is allowed, but
not required, by this framework.
Wu, et al. [Page 20]
Internet Draft draft-wu-softwire-mesh-framework-01.txt October 2006
9. Choosing to Forward Through a Softwire
The decision to forward through a softwire, instead of to forward
natively, is a matter of policy.
In many cases, the policy will be very simple. Some useful policies
are:
- if routing says that an AF(c) packet has to be sent out a "core-
facing interface", send the packet through a softwire
- if routing says that an AF(c) packet has to be sent out an
interface that only supports AF(b) packets, then send the AF(c)
packets through a softwire
- if routing says that the BGP next hop address for an AF(c) packet
is an AF(b) address, then send the AF(c) packets through a
softwire
- if the route which is the best match for a particular packet's
destination address is a BGP-distributed route, then send the
packet through a softwire (i.e., tunnel all BGP-routed packets).
More complicated policies are also possible, but a considerations of
those policies is outside the scope of this document.
10. Selecting a Tunneling Technology
This framework allows a variety of tunneling technologies to be used
for instantiating softwires. The choice of tunneling technology is a
matter of policy, as discussed in section 2.
While in many cases the policy will be unconditional, e.g., "always
use L2TPv3 for softwires", in other cases the policy may specify that
the choice is conditional upon information about the softwire remote
endpoint, e.g., "use L2TPv3 to talk to routers in class X, use GRE to
talk to routers in class Y". It is desirable therefore to allow the
network administration to create a small set of classes, and to
configure each AFBR to be a member of one or more of these classes.
If each such class is represented as a community or extended
community, then [draft-pmohapat-idr-info-safi] specifies a method
that AFBRs can use to advertise their class memberships to each
other.
This framework also allows for policies of arbitrary complexity,
which may depend on characteristics or attributes of individual
address prefixes, as well as on QoS or security considerations.
Wu, et al. [Page 21]
Internet Draft draft-wu-softwire-mesh-framework-01.txt October 2006
However, the specification of such policies is not within the scope
of this document.
11. Selecting the Softwire for a Given Packet
Suppose it has been decided to send a given packet through a
softwire. Routing provides the address, in the AF(b) family, of the
BGP next hop. The packet MUST be sent through a softwire whose
remote endpoint address is the same as the BGP next hop address.
Sending a packet through a softwire is a matter of encapsulating the
packet with an STH and then transmitting towards the softwire's
remote endpoint address.
In many cases, once one knows the remote endpoint address, one has
all the information one needs in order to form the STH. This will be
the case if the tunnel technology instantiating the softwire is,
e.g., LDP-based MPLS, IP-in-IP, or GRE without optional header
fields.
If the tunnel technology being used is L2TPv3 or GRE with optional
header fields, additional information from the remote endpoint is
needed in order to form the STH. The procedures for sending and
receiving this information are described in [draft-pmohapat-idr-
info-safi].
If the tunnel technology being used is RSVP-TE-based MPLS or IPsec,
the native signaling procedures of those technologies will need to be
used.
IPsec procedures will be discussed further in a subsequent revision
of this document.
RSVP-TE procedures will be discussed in companion documents.
If the packet being sent through the softwire matched a route in the
labeled IPv4 or labeled IPv6 address families, it should be sent
through the softwire as an MPLS packet with the corresponding label.
Note that most of the tunneling technologies mentioned in this
document are capable of carrying MPLS packets, so this does not
presuppose support for MPLS in the core routers.
Wu, et al. [Page 22]
Internet Draft draft-wu-softwire-mesh-framework-01.txt October 2006
12. Softwire OAM and MIBs
12.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 (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.
Wu, et al. [Page 23]
Internet Draft draft-wu-softwire-mesh-framework-01.txt October 2006
12.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.
13. Softwire Multicast
A set of client networks, running AF(c), that are connected to a
provider's AF(b) transit core, may wish to run IP multicast
applications. Extending IP multicast connectivity across the transit
core can be done in a number of ways, each with a different set of
characteristics. Among them are:
- Extend each client multicast tree through the transit core, so
that for each client tree there is exactly one tree through the
core.
- Use one multicast tree in the core, add all the AFBRs to it, make
it look to the client multicast control protocols as if the
transit network is a LAN over which they can run transparently.
- Use more than one multicast tree in the core, but less than one
per client tree, and perform some kind of aggregation of client
trees to core trees.
- Don't use any multicast trees in the core, have the ingress AFBRs
replicate the multicast traffic and then unicast each replica.
This list does not exhaust the set of alternatives. There are also
additional issues which are somewhat orthogonal, such as whether it
is best for the transit core and the clients to be using the same
multicast control protocols or not, what multicast control protocols
and service models need to be supported, etc.
All these issues will be considered more fully in a subsequent
revision of this document.
Wu, et al. [Page 24]
Internet Draft draft-wu-softwire-mesh-framework-01.txt October 2006
14. Inter-AS Considerations
We have so far only considered the case where a "transit core"
consists of a single Autonomous System (AS). If the transit core
consists of multiple ASes, then it may be necessary to use softwires
whose endpoints are AFBRs attached to different Autonomous Systems.
In this case, the AFBR at the remote endpoint of a softwire is not
the BGP next hop for packets that need to be sent on the softwire.
Since the procedures described above require the address of remote
softwire endpoint to be the same as the address of the BGP next hop,
those procedures do not work as specified when the transit core
consists of multiple ASes.
There are two ways to deal with this situation.
1. Don't do it; require that there be AFBRs at the edge of each
AS, so that a transit core does not extend more than one AS.
2. Specify a new BGP attribute that allows an AFBR to identify
itself without using the NH field. This "next AFBR" attribute
would be passed unchanged by non-AFBRs, but each AFBR
disseminating a given routing update would replace any existing
"next AFBR" attribute by its own address. When an ingress AFBR
is choosing a softwire to send a packet through, if a "next
AFBR" attribute is present, it would use that rather than the
next hop to help it choose the proper softwire.
15. 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.
16. Acknowledgments
David Ward, Chris Cassar, Gargi Nalawade, Ruchi Kapoor, Pranav Mehta,
Mingwei Xu and Ke Xu provided useful input into this document.
Wu, et al. [Page 25]
Internet Draft draft-wu-softwire-mesh-framework-01.txt October 2006
17. References
[RFC2119] "Key words for use in RFCs to Indicate Requirement
Levels.", Bradner, S., March 1997.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC3031] "Multiprotocol Label Switching Architecture", Rosen, E.,
Viswanathan, A., Callon, R., January 2001.
[RFC3032] "MPLS Label Stack Encoding", Rosen, E., Tappan, D.,
Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., Conta, A., January
2001.
[RFC3036] "LDP Specification", Andersson, L., Doolan, P., Feldman,
N., Fredette, A., Thomas, B., January 2001.
[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.
[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.
[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.
Wu, et al. [Page 26]
Internet Draft draft-wu-softwire-mesh-framework-01.txt October 2006
[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-lefaucheur-idr-v4nlri-v6nh] Le Faucheur, F., Rosen, E.,
"Advertising an IPv4 NLRI with an IPv6 Next Hop", draft-lefaucheur-
idr-v4nlri-v6nh-00.txt, October 2006.
[draft-ooms-v6ops-bgp-tunnel] De Clercq, J., Ooms D., Prevost S., Le
Faucheur F., "Connecting IPv6 Islands over IPv4 MPLS using IPv6
Provider Edge Routers (6PE)", draft-ooms-v6ops-bgp-tunnel-06.txt,
January 2006.
[draft-pmohapat-idr-info-safi] Mohapatra, P., Rosen, E. "BGP
Information SAFI and BGP Tunnel Encapsulation Attribute", draft-
pmohapat-idr-info-safi-00.txt, September 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
Wu, et al. [Page 27]
Internet Draft draft-wu-softwire-mesh-framework-01.txt October 2006
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
USA
Email: chmetz@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
USA
Email: pmohapat@cisco.com
Wu, et al. [Page 28]
Internet Draft draft-wu-softwire-mesh-framework-01.txt October 2006
John Scudder
Cisco Systems, Inc.
3700 Cisco Way
San Jose, Ca. 95134
USA
Email: jscudder@cisco.com
18. Full 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.
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.
19. Intellectual Property
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
Wu, et al. [Page 29]
Internet Draft draft-wu-softwire-mesh-framework-01.txt October 2006
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.
Wu, et al. [Page 30]