190 likes | 205 Views
Softwire Mesh Solution Framework. Jianping Wu, jianping@cernet.edu.cn Yong Cui, yong@csnet1.cs.tsinghua.edu.cn Chris Metz, chmetz@cisco.com IETF Softwires WG Meeting, Dallas March 2006. Contents. High-Level One Slide Terminology Problem to Solve Requirements Solution Framework
E N D
Softwire Mesh Solution Framework Jianping Wu, jianping@cernet.edu.cn Yong Cui, yong@csnet1.cs.tsinghua.edu.cn Chris Metz, chmetz@cisco.com IETF Softwires WG Meeting, Dallas March 2006
Contents • High-Level One Slide • Terminology • Problem to Solve • Requirements • Solution Framework • Consensus from Hong Kong Interim Meeting • Next Steps
High-level One Slide AF/SAF Reachability, softwire tunnel info • 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 tunnel Single AF Transit Network AF/SAF Island Network 2 AFBR #2 AF/SAF Island Network 1 AFBR #1 AF/SAF Island Network 3 AFBR #3 softwire
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
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
Terminology (3) AF(i) Island Network Single AF(j) Transit Network AFBR(I,j) AF(i) 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 AFBR(I,j) AF(I,j) Island Network AFBR(I,j) AF(i) Island Network AFBR(I,j) AF(j) Island Network
Basic Problem to Solve • Support inter-AF(i) connectivity across a single AF(j) transit network • e.g. IPv4-over-IPv6 Single AF(j) Transit Network AF(i) Island Network 2 AFBR(I,j) #2 AF(i) Island Network 1 AFBR(I,j) #1 AF(i) Island Network 3 AFBR(I,j) #3
So what is needed here? AF(i) Island Network 1 AFBR(I,j) #1 Single AF(j) Transit Network • 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 AF(i) Island Network 2 AFBR(I,j) #2 AF(i) Island Network N AFBR(I,j) #N
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
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
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
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
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
IP IPv6/IPv4 IPv6/VPN label/IPv4 - UDP/IP IPv6/UDP/IPv4 GRE IPv6/GRE/IPv4 IPv6/VPN Label/GRE/IPv4 IPsec IPv6/IPsec/IPv4 MPLS if IPv4 transit is MPLS-enabled then MPLS label may be pushed on top or replace outer IPv4 header L2TPv3 IPv6/L2TPv3/IPv4 IPv6/VPN label/L2TPv3/IPv4 IPv6/L2TPv3/IPsec/IPv4 IPv6/VPN label/L2TPv3/IPsec/IPv4 IPv6/L2TPv3/UDP/IPv4 Softwire Encapsulation Possibilities(over IPv4 Transit)
IPv6 only IPv4/IPv6 IPv4/VPN label/IPv6 UDP/IP only IPv4/UDP/IPv6 GRE IPv4/GRE/IPv6 IPv4/VPN Label/GRE/IPv6 IPsec IPv4/IPsec/IPv6 MPLS if IPv6 transit is MPLS-enabled then MPLS label may be pushed on top or replace outer IPv6 header L2TPv3 IPv4/L2TPv3/IPv6 IPv4/VPN label/L2TPv3/IPv6 IPv4/L2TPv3/IPsec/IPv6 IPv4/VPN label/L2TPv3/IPsec/IPv6 IPv4/L2TPv3/UDP/IPv6 Softwire Encapsulation Possibilities(over IPv6 Transit)
Consensus Actionsfrom 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.)
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
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