Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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