Transcript PPT Version

Softwire Mesh Solution
Framework
Jianping Wu, [email protected]
Yong Cui, [email protected]
Chris Metz, [email protected]
IETF Softwires WG Meeting, Dallas
March 2006
1
Contents
•
•
•
•
•
•
High-Level One Slide
Terminology
Problem to Solve
Requirements
Solution Framework
Consensus from Hong Kong Interim
Meeting
• Next Steps
2
High-level One Slide
AF/SAF Reachability,
softwire tunnel info
AF/SAF Island
Network 1
AFBR
#1
Single AF Transit
Network
AFBR
#2
AF/SAF Island
Network 2
AFBR
#3
AF/SAF Island
Network 3
softwire
•
Tunnel the packets of one or more address families (AF/SAF) across a
single inter-AF transit network
– AF/SAF(s) can be IPv4, IPv6, VPNv4, VPNv6, etc. and originate/terminate in
AF/SAF Island Networks
– single AF transit network is IPv4 or IPv6
– tunnels between edge routers (AFBR) are called Softwires and use existing
encaps (e.g. GRE, L2TPv3, etc.)
– use routing protocol (e.g. MP-BGP) between edge routers (AFBRs) to announce
softwire tunnel type/encaps/prefs and AF/SAF reachability thru the softwire
3
tunnel
Terminology (1)
• Address Family (AF) – IPv4 or IPv6
• Subsequent Address Family (SAF) – additional info
about AF (e.g. unicast, multicast, VPN, etc.)
• Address Family Border Router (AFBR) – dual stack
router that connects two address families
– peers with other AFBRs and downstream CPE routers
– distributes and stores AF/SAF prefixes in VRF and/or global
tables
– establishes and maintains softwire tunnels with other AFBRs
– performs encap/decap function on softwire tunnel headers
4
Terminology (2)
• Softwire (SW) – pt-pt (or mpt-pt) tunnel
established between two or more SW end-points
(AFBR)
• Softwire Transport Header (STH AF) – address
family of the outermost IP header of the packet
flowing on the softwire
• Softwire Payload Header (SPF AF) – address
family of the IP packet encapsulated and
transported across the softwire
5
Terminology (3)
AF(i) Island
Network
AFBR(I,j)
AFBR(I,j)
AF(i) Island
Network
AFBR(I,j)
AF(i) Island
Network
Single AF(j) Transit
Network
AF(I,j) Island
Network
AFBR(I,j)
AF(j) Island
Network
• AF Island Network – single or multi-AF network that is
single- or multi-homed to dual-stack AFBR nodes
• Single AF Transit Network – single AF transit network
providing routing/forwarding between AFBR nodes
6
Basic Problem to Solve
AF(i) Island
Network 1
AFBR(I,j)
#1
Single AF(j) Transit
Network
AFBR(I,j)
#2
AF(i) Island
Network 2
AFBR(I,j)
#3
AF(i) Island
Network 3
• Support inter-AF(i) connectivity across a single AF(j)
transit network
– e.g. IPv4-over-IPv6
7
So what is needed here?
AF(i) Island
Network 1
AFBR(I,j)
#1
Single AF(j) Transit
Network
AF(i) Island
Network N
•
AFBR(I,j)
#2
AF(i) Island
Network 2
AFBR(I,j)
#N
Softwire tunnel discovery
– so that egress AFBR #2 can tell AFBRs (#1,…,#N) the tunnel types/encaps/prefs
it can support
•
Multi-AF/SAF Reachability
– so that egress AFBR #2 can tell AFBRs (#1,…, #N) what AF/SAF prefixes are
reachable through it
•
Way to associate AF/SAF reachability to the softwire
– so ingress AFBRs (#1,…,#N) will know which softwire to use when forwarding
packets to AF/SAF prefixes reachable through AFBR #2
•
Softwire Tunnel Encaps
– so packets sourced from the AF(i) island network can be transparently forwarded
across single AF transit network
8
Other Requirements to Consider
(1)
• Scalability
– AFBR peering: O(# of peering AFBR + # of CPE routers)
– AFBR routes: O(global Internet + # AF/SAF island prefixes)
• AF/SAF Reachability
– not limited to VPN AF/SAF combinations (e.g. AF=x, SAF=128)
– must support tunneling of any AF/SAF combination (like IPv4-over-IPv6)
• Softwire Encaps
– must support different encaps
– possible for AFBR to support more than one encap type (e.g. GRE,
IPsec) and express a preference for one
– different AF/SAF prefixes may use different encaps
• Multicast
– support native AF/SAF multicast routing/forwarding across single AF
transit network
9
Other Requirements to Consider
(2)
• Use existing protocols where possible
– e.g. re-use the hub-spoke encap
• Time-to-market
– consider what is already deployed and working
10
Solution Framework (1)
Basic Idea
• Leverage and reuse existing protocols where appropriate
– MP-BGP can carry multiple AF/SAFs
– multiple tunnel encaps already exist (e.g. L2TPv3, IPv4-in-IPv6)
– lots of code, experience and deployments supporting large scale
VPN AF/SAF reachability across transit networks (e.g. MPLS, IP)
• Extend MP-BGP to
– enable egress AFBR(s) to advertise their softwire tunnel
capabilties, encapsulation parameters and preferences to
participating ingress AFBR nodes … thus forming the softwire
mesh
– connect AF/SAF reachability to a softwire
11
Solution Framework (2)
12
Solution Framework (3)
Notes
• General AF(i)-over-AF(j) solution
– must support any AF/SAF combination like
IPv4-over-IPv6
• Leverage existing tunnel signaling
machinery where appropriate
13
Solution Framework (4)
MP-BGP Notes
• Comes with scalability (e.g. route reflectors),
interoperable multi-AF/SAF reachability deployments
(RFC4364) and policy controls (e.g. no-export)
• Softwire tunnel extensions:
– AFBR express softwire support using BGP capabilities
– egress AFBR announces softwire tunnel types, encap
parameters and preferences
– associate AF/SAF reachability with softwire and be as efficient
as possible
– Tunnel SAFI is one possibility … Tunnel Encapsulation Attribute
defines tunnel type/encap/preference and is carried by MP-BGP
14
Softwire Encapsulation Possibilities
(over IPv4 Transit)
• IP
– IPv6/IPv4
– IPv6/VPN label/IPv4 -
• UDP/IP
– IPv6/UDP/IPv4
• GRE
– IPv6/GRE/IPv4
– IPv6/VPN Label/GRE/IPv4
• L2TPv3
–
–
–
–
IPv6/L2TPv3/IPv4
IPv6/VPN label/L2TPv3/IPv4
IPv6/L2TPv3/IPsec/IPv4
IPv6/VPN
label/L2TPv3/IPsec/IPv4
– IPv6/L2TPv3/UDP/IPv4
• IPsec
– IPv6/IPsec/IPv4
• MPLS
– if IPv4 transit is MPLSenabled then MPLS label may
be pushed on top or replace
outer IPv4 header
15
Softwire Encapsulation Possibilities
(over IPv6 Transit)
• IPv6 only
– IPv4/IPv6
– IPv4/VPN label/IPv6
• UDP/IP only
– IPv4/UDP/IPv6
• GRE
– IPv4/GRE/IPv6
– IPv4/VPN Label/GRE/IPv6
• L2TPv3
–
–
–
–
IPv4/L2TPv3/IPv6
IPv4/VPN label/L2TPv3/IPv6
IPv4/L2TPv3/IPsec/IPv6
IPv4/VPN
label/L2TPv3/IPsec/IPv6
– IPv4/L2TPv3/UDP/IPv6
• IPsec
– IPv4/IPsec/IPv6
• MPLS
– if IPv6 transit is MPLSenabled then MPLS label may
be pushed on top or replace
outer IPv6 header
16
Consensus Actions
from Honk Kong Interim meeting
• Agreed to merge two efforts
– draft-wu-softwire-4over6-00 & C. Metz BGP Tunnel SAFI+
presentation
•
Softwire Mesh Framework
– AFBRs use MP-BGP to announce softwire tunnel
types/encaps/prefs, AF/SAF reachability and softwire tunnel to
use
– establish baseline set of IP(x)-over-IP(y) encaps
– Present Softwire Mesh Framework in Dallas – DONE 
– Commence effort on Softwire Mesh Framework draft after Dallas
IETF
– build on Tunnel SAFI notion in Softwires WG with review from
various related WG (i.e. L2VPN, L3VPN, IDR, Security, etc.)
17
Next Steps
• Softwire Mesh Framework Draft
• Supporting MP-BGP softwire tunnel drafts
– Tunnel SAFI idea
– support for IPsec control/encap
• Tie in to the Multicast efforts
– e.g. draft-ietf-softwires-4over6vpn.txt
18
References
•
•
•
•
http://tools.ietf.org/wg/softwire/
draft-wu-softwire-4over6-00.txt
draft-nalawade-kapoor-tunnel-safi-04.txt
Wu, J., et al., “The Transition to IPv6 Part I:
4over6 for the China Education and Research
Network”, IEEE Internet Computing, Summer
2006
19