190 likes | 315 Vues
This presentation discusses the framework for softwires, enabling the tunneling of multiple address families (AFs) across a unified transit network. It outlines the key terminologies, challenges in achieving inter-AF connectivity, and proposed solutions to address these limitations. The implementation of softwire tunnels, routing protocols, and encapsulation methods are covered to facilitate seamless communication between IPv4, IPv6, and VPN address families. The framework aims to leverage existing protocols and prepare for future scalability while addressing multicast and routing efficiency.
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