irtf rrg activity for future internet
DESCRIPTION
IRTF RRG Activity for Future Internet. Heeyoung JUNG. ETRI. Email: [email protected]. Outline. Internet and why Future Internet? IRTF and RRG Overview RRG Documents LISP and ILNP Wrap Up. Internet. Network of networks (Not WWW ) Global inter-networking technology - PowerPoint PPT PresentationTRANSCRIPT
Outline
• Internet and why Future Internet?• IRTF and RRG Overview• RRG Documents• LISP and ILNP• Wrap Up
2heeyoung, ETRI
Internet
• Network of networks (Not WWW )– Global inter-networking technology– But becoming a single basic tech for all kinds of
networks (e.g. All-IP networks)
• Core protocols– IPv4/v6 (network) + TCP/UDP (transport) + WWW
(application)
• A single power group– Standard: IETF, leaded a few big guys– Product: Cisco, more than 70% market share
3heeyoung, ETRI
Basic Concepts
• Hourglass model
4heeyoung, ETRI
Various applications
Various underlying
technologies
Common Thin waist
• End-to-End argument
Stupid Network(just delivery)
Intelligent end host
Apps &
Control
Apps &
Control
Telecom networks (beads-on-a-string, dummy terminals/smart network)
What’s been Happened?
• On 1 January 1983, all ARPANnet switched to TCP/IP– Internet has had no big change since the flag day
• But, environment has been continuously changed– Research network for commercial networks, or a social
infra– Best effort services including QoS/E guaranteed services– Well-educated technician Ordinary people– Reliable users Lots of bad guys– Fixed oriented Mobile oriented– A few apps www, google, twitter, facebook, …– And lots of other things
5heeyoung, ETRI
Ossification
6heeyoung, ETRI
Fat waist
Peak ?
Need Something New
7heeyoung, ETRI
Internet
(Clean-slate) Future
Internet?
Future Internet Activities
• Typically classified as Arch and Experimental Facility (EF)• US
– Mainly funded by NSF– Arch: MobilityFirst, NDN, Nebula, and XIA– EF: GENI
• EU– Mainly supported through FP7 projects– Arch: 4WARD, PSIRP, ANA, etc.– EF: FIRE
• Japan– Mainly leaded by NICT as a part of NWGN– Arch: AKARI (ID/LO split, network virtualization and optical packet)– EF: JGN2plus
8heeyoung, ETRI
FI in Korea
• KCC/KCA FI PM– 6 on-going projects (Arch and EF)– 4 new projects (Arch): NDN, DTN, Trusty net, and Smart
node– Performed by ETRI and universities, including SNU
• Future Internet Forum (FIF)– http://fir.kr– Chaired by YH Choi
9heeyoung, ETRI
Any Conclusion for FI?
• Seems NO
• A golden opportunity for Korea to contribute our ideas
10heeyoung, ETRI
DTN
IETF and IRTF
• Two powerful organizations of US • IETF
– Focuses on the shorter term issues of engineering and standards making
• IRTF– Focuses on longer term research issues related to the
Internet while the parallel organization, the IETF– Still focus on evolution
11heeyoung, ETRI
• Research Groups1. ASRG: Anti-Spam Research Group 2. CFRG: Crypto Forum Research Group 3. DTNRG: Delay-Tolerant Networking Research Group4. HIPRG: Host Identity Protocol Research Group5. ICCRG: Internet Congestion Control Research Group6. MOBOPTS: IP Mobility Optimizations Research Group7. NMRG: Network Management Research Group8. P2PRG: Peer-to-Peer Research Group 9. RRG: Routing Research Group10.SAMRG: Scalable Adaptive Multicast Research Group11.TMRG: Transport Modeling Research Group12.VNRG: Virtual Networks Research Group
12heeyoung, ETRI
IRTF RGs
Security
Wireless
Scalability/Mobility
Transport
Management
P2P
Virtualization
Problem Statement of RRG
• Internet addresses initially assigned in hierarchical manner– Address aggregation for inter-domain routing
• However, aggregation is becoming more and more difficult– Multi-homing, provider change, assignment of new address
blocks, etc.
13heeyoung, ETRI
BGP RT Explosion
• The most imminent problem of Internet
14heeyoung, ETRI
Size of current
BGP FIB?
Related Documents
• Report from the IAB workshop (Oct. 2006) on routing and addressing
– RFC4984, Sep. 2007– Editors: David Meyer (Cisco), Lixia Zhang(UCLA) and Kevin Fall
(Intel)
• On the scalability of Internet routing– Draft-narten-radir-problem-statement-05.txt, Feb. 17, 2010– Author: Thomas Narten(IBM)
• Design goals for scalable Internet routing– Draft-irtf-rrg-design-goals-06.txt, Jan. 3, 2011– Editor: Tony Li (Cisco)
• Recommendation for a routing architecture– RFC6115, Feb. 2011– Chairs: Tony Li (Cisco) and Lixia Zhang (UCLA)
15heeyoung, ETRI
RFC4984
• Report from IAB WS
• Problem statement– Commonly recognized that today’s Internet routing and
addressing system is facing serious scaling problem– Effective solutions have yet to be identified, developed, and
deployed
• Main objectives of WS– To identify existing and potential factors that major impacts
on routing scalability– To develop a concise problem statement that may serve as
input to a set to follow-on activities
16heeyoung, ETRI
Key Findings
• Problem #1: the scalability of routing system• Problem #2: the overloaded of IP address
semantics• Other concerns– Scaling problem can potentially be exacerbated by IPv6’s
much largerer address space– The growth in number of routers will cause slow routing
convergence to become a significant problem– Misalignment of costs and benefits in today’s routing
system• IETF does not consider “business model”, but the
time has come to review that philosophy
17heeyoung, ETRI
On the scalability of Internet routing
• Based on 2006 IAB WS on routing & addressing [RFC4984]– Describes the "pain points" being placed on the routing system
• Background– Within DFZ, both the size of the RIB/FIB and overall update rate
have historically increased at a greater than linear rate : super-linear growth
– Challenge for current and/or future routers
• Factors that make CIDR aggregation difficult– Traffic engineering (TE), multi-homing, end site renumbering,
acquisitions and merges, RIR address allocation policies, dual stack pressure on the routing table, internal customer routes, IPv4 address exhaustion, interconnection richness, …
18heeyoung, ETRI
Design Goals for Scalable Internet Routing
• Background – Internet routing and addressing architecture is facing
challenges in inter-domain scalability, mobility, multi-homing, and inter-domain traffic engineering[IAB WS-RFC4984]
– RRG aims to design an alternative architecture to meet these challenges
• Presents a prioritized list of design goals for the target architecture
19heeyoung, ETRI
Priority
20heeyoung, ETRI
No. Design goals Priority
1 Scalability Strongly desired
2 Traffic engineering Strongly desired
3 Multi-homing Strongly desired
4 Loc/id separation Desired
5 Mobility Desired
6 Simplified renumbering Strongly desired
7 Modularity Strongly desired
8 Routing quality Strongly desired
9 Routing security Required
10 Deployability Required
RFC 6115-(1)
• Background – RRG was chartered to research and recommend a new routing
architecture for the Internet– The goal was to explore many alternatives (15+1) and build
consensus around a single proposal– Meetings from Mar. 2007 to Mar. 2010
• A general concern on the cost and structure of routing and addressing architecture– Urgent need to examine and evaluate potential scalability
enhancements– The new architecture must be applicable to IPv6– Many of Band-Aid solutions have come with a significant
overhead in terms of long-term maintenance and architecture complexity
21heeyoung, ETRI
RFC 6115-(2)
• Consensus– Rough consensus on ID/LOC split but not on a specific
approach– Internet needs to support multi-homing in a manner that
scales well and does not have prohibitive costs– IETF solution has to not only support multi-homing, but
address the real-world constraints of the end customers
• Co-chairs recommend that the IETF pursues works in the following areas:– Evolution: a short-term improvement– ILNP: a clean solution for the architecture– Renumbering: change locators at minimal cost
22heeyoung, ETRI
Brief Summary –(1)
• ID/LOC split schemes: makes LOCs topologically aggregatable
23heeyoung, ETRI
No.
Ideas (Author) Features
1 LISP (Cisco, US)-Edge-Core network separation (EID-RLOC)- Various mapping systems(e.g. LISP-ALT,-TREE,-MS,-DHT)
2RANGI (Huawei, China)
-Hierarchical 128 bit Host ID and Locator (HIP-like)
-Hierarchical DHT-based mapping system (ID:LOC)
3GLI-Split (G-Lab, German)
-Separation b/w global routing and local routing (IPv6 address=ID+LL(Edge)/GL(Core))
- Local/Global mapping system (ID-LL, ID-GL)
4Name Overlay Service (Tsinghua Univ., China)
-Add a name overlay (NOL) onto TCP/IP stack- Initiating and mapping transport connection channel by name
5Name Based Socket (SICS, Sweden)
Apps initiate and receive communication session based on domain name(e.g. ietf.host.org) instead of IP address
6ILNP (University of St Andrews, UK)
-128bit IPv6 address --> 64bit LOC + 64bit ID- Dynamic DNS as ID:LOC mapping system
Brief Summary –(2)
• Cont’d
24heeyoung, ETRI
No.
Ideas (author) Features
7IRON-RANGER (Boeing, US)
-Edge (EID) and Transit (RLOC) separation- Mapping system is similar to global DNS
8hIPv4 (First Principles, Australia)
-Regional unique endpoint locator (ELOC) and global unique area locator (ALOC)
-Shim header b/w IP and TCP, and locator swap router in ALOC realm
9 TIDR (GISS, Spain)-Tunneling b/w edge routers-Mapping is maintained in TIBs (not included in RIB)
Brief Summary –(3)
• Effective mapping systems for ID/LOC split – Mostly related to LISP
25heeyoung, ETRI
No.
Ideas (author) Features
1 EEMDP (NIST, US)
-Mapping distribution protocol for LISP-ETR’s regional Mapping Server (ILM-R) pushes mapping information toward ILMs for quick response
2IvIP (First Principles, Australia)
-Global fast-push mapping distribution network like cross-linked multicast tree
-Push all mapping changes to full-DB query servers (QSDs) within ISP within a few seconds
3Two-phased mapping (unknown)
-Introduce an AS # in the middle of prefix:ETR mapping
-Prefix:AS# (Phase I) and AS#:ETRs (Phase II)
4Compact routing mechanism (NSN)
-Dynamic topology adaption to facilitate efficient aggregation (landmark based routing)
- Map servers as cluster heads or landmark
5Layered mapping system (Tsinghua Univ.)
-Hierarchical mapping system-Bottom: EID-LOC, Upper: indexing EID (/0, /16, /24, …)
Brief Summary –(4)
• Other approaches
26heeyoung, ETRI
No.
Ideas (author) Features
1Evolution (UCLA)
-Optimization of routing table size by enhancing aggregation
-Cooperation b/w routers or introducing virtual router concept
2Renumbering (IAB)
Change IP addressing information associated with a host or site
Evolution
• Observation– Changes to the Internet can only be a gradual process
with multiple stages– At each stage, adopters are driven by and rewarded with
solving an immediate problem
• Basic approach– Aggregating many routing entries to a few number
• Examples
27heeyoung, ETRI
Pros & Cons
• Merits– The lowest hurdle to deployment
• Does not require that all networks move to use a global mapping system or upgrade all hosts
– Immediate benefits to ISP after its own deployment
• Critics– Potential concerns in the technical design
• FIB aggregation may introduce extra routing space that causes potential routing loop
• Many potential side-effects in virtual aggregation • Not provide mobility support
– Would end up with adding more and more patch to the old arch• Just short-term solution to reduce the incentives for
deploying a new arch
28heeyoung, ETRI
Two Promising Techs
• LISP– Supported by Cisco– The most typical approach for ID/LOC split
• Already many Internet drafts and some implementations
– Note that many other proposals are closely related to LISP
• ILNP– Recommended by RRG as the clean-slate approach– Likely to be discussed in IETF
29heeyoung, ETRI
Key Ideas of LISP
• Implements a ID/LOC separation mechanism using encapsulation between routers at the "edge" of the Internet– Generally called, Map & Ecap
• Allows topological aggregation of the routable addresses (LOCs)– While providing stable and portable numbering of end
systems (IDs)
30heeyoung, ETRI
Gains
• Topological aggregation of locator space (RLOCs) used for routing– Greatly reduces both the overall size and the "churn rate“ of
the information needed to operate the Internet global routing system
• Separate identifier space (EIDs) for end systems– Effectively allowing "PI for all“ without adding state to the
global routing system
• Improved traffic engineering capabilities • No changes required to end systems and to Internet
"core" routers• Minimal and straightforward changes to "edge"
routers• Day-one advantages for early adopters
31heeyoung, ETRI
Cost
• Mapping system infrastructure– Alternative Logical Topology (ALT) routers, Map Servers,
Map Resolvers, – New business opportunity
• Overhead for determining/maintaining locator/path liveness– A common issue for all ID/LOC separation proposals
• Interworking infrastructure (ITRs, ETRs)– New business opportunity
32heeyoung, ETRI
Data Plane
33heeyoung, ETRI
Provider A10.0.0.0/8
Provider B11.0.0.0/8
S
ITR
DITR
ETR
ETR
Provider Y13.0.0.0/8
Provider X12.0.0.0/8
S1
S2
D1
D2
PI EID-prefix 1.0.0.0/8 PI EID-prefix 2.0.0.0/8
DNS entry:D.abc.com A 2.0.0.2
EID-prefix: 2.0.0.0/8
Locator-set:
12.0.0.2, priority: 1, weight: 50 (D1)
13.0.0.2, priority: 1, weight: 50 (D2)
Mapping
Entry
1.0.0.1 -> 2.0.0.2
1.0.0.1 -> 2.0.0.2
11.0.0.1 -> 12.0.0.2
Legend:
EIDs -> Blue
Locators -> Red
1.0.0.1 -> 2.0.0.2
11.0.0.1 -> 12.0.0.2
1.0.0.1 -> 2.0.0.2
12.0.0.2
13.0.0.2
10.0.0.1
11.0.0.1
Policy controlledby destination site
Source: David Meyer, “LISP, What Is It, And How Much Of It Is Real?” 2008
Control Plane
• ALT (Alternative Logical Topology) is the most popular solution
• The ALT is just an instance of BGP that carries EID prefixes– ETRs typically advertise EID-prefixes into the ALT to
attract Map-Requests– ITRs use the ALT to route Map-Requests to the ETRs that
are authoritative for an EID prefix– ETRs return Map-Replies on the underlying network to
the requesting ITR – The ITR can now LISP-encapsulate packets directly to the
destination’s ETR
34heeyoung, ETRI
LISP-ALT Operation
35heeyoung, ETRI
Legend:
EIDs -> Blue
Locators -> Red
GRE Tunnel
Low Opex
Physical link
Data Packet
Map-Request
Map-Reply
ETR
ETR
ETR
ITR
EID-prefix
240.1.2.0/24
ITR
EID-prefix
240.1.1.0/24
ALT EID-prefix
240.2.1.0/24
240.0.0.1 -> 240.1.1.1
1.1.1.1
2.2.2.2
3.3.3.3
240.0.0.1 -> 240.1.1.1EID-prefix
240.0.0.0/24
1.1.1.1 -> 11.0.0.1240.0.0.1 -> 240.1.1.1
11.0.0.1 -> 1.1.1.1
ALT-rtr
ALT-rtr
ALT-rtr
ALT-rtr
ALT-rtr
ALT-rtr
12.0.0.1
11.0.0.1
?
240.0.0.1 -> 240.1.1.1
11.0.0.1 -> 240.1.1.1
? 240.0.0.1 -> 240.1.1.1
11.0.0.1 -> 240.1.1.1
?<- 240.1.1.0/24
<- 240.1.2.0/24
< - 240.1.0.0/16 ?
Source: David Meyer, “LISP, What Is It, And How Much Of It Is Real?” 2008
Critique
• A fundamental problem with any global query server network– Frequently long paths and greater risk of packet loss may
cause ITRs drop or significantly delay the initial packets – ALT's delays compounded by its structure being
aggressively aggregated, without regard to the geographic location of the routers
• No solution for the contradiction b/w– The need for high aggregation while making ALT structure
robust against single points of failure
• Testing reachability of the ETRs is complex and costly
• Complex communication between ITRs and ETRs– UDP and 64-bit LISP headers in all traffic packets
36heeyoung, ETRI
Rebuttal
• Initial-packet loss/delays turn out not to be a deep issue– If needed, initial packets can be sent via legacy
mechanism until the ITR has a mapping
• ALT is never mandatory in the long term– LISP has a standardization mapping system interface for
new mapping systems
37heeyoung, ETRI
ILNP
• Motivation– If we provide a richer set of namespaces, then the
Internet architecture can better support mobility, multi-homing, and other important capabilities
• Key ideas– Clean separation of IDs from LOCs– ID names nodes, not interface– LOCs names sub-networks, equivalent to an IP routing
prefix– IDs are never used for network-layer routing
• Whilst LOCs are never used for node ID– Transport layer sessions use only ID, never LOC
38heeyoung, ETRI
Naming: IP vs. ILNP
39heeyoung, ETRI
e.g.‘marston.cs.st-andrews.ac.uk’
Saleem Bhatti, “Naming for Networking,” 2008
• ILNPv6 splits the IPv6 address in half– Locator (L): 64-bit name for the sub-network– Identifier (I): 64-bit name for the host
Address: IPv6 vs. ILNPv6
40heeyoung, ETRI
Saleem Bhatti, “Naming for Networking,” 2008
Header Format
41heeyoung, ETRI
Source
address
Destination
address
Saleem Bhatti, “Naming for Networking,” 2008
Mobility in ILNPv6
• Implementation in CN– Uses DNS to find MN’s set of Identifiers and Locators– Only uses ID in transport-layer session state– Uses LOC only to forward/route packets
• Implementation in MN– Accepts new sessions using currently valid “I” values– When the MN moves:
• ICMP Locator Update (LU) to inform other nodes of revised set of Locators for the MN
• LU can be authenticated via IP Security• Secure Dynamic DNS Update to revise its LOC in its
Authoritative DNS server
42heeyoung, ETRI
ILNP Session Setup
43heeyoung, ETRI
Avinash Mungur, “Analysis of Locator Identity Split Protocols in Providing End-host Mobility,” Lancaster University
Others with ILNP
• Support both site multi-homing & host multi-homing– ICMP LU mechanism handles uplink changes
• Topologically aggregatable LOCs helps BGP scalability
• Eliminates issues with NAT– Upper-layer protocol state is bound to I only, never to L– Only value of L changes as the NAT is traversed, so NAT
function now invisible to upper-layer protocols
• IP Security with ILNP– ILNP AH includes I values, but excludes L values– IPsec Security Association (SA) bound to value of I, not L– Existing IETF DNS Security can be used as-is
44heeyoung, ETRI
Cost
• End systems need to be enhanced to support ILNP
• DNS servers also should be upgraded to support new DNS resource records for ILNP
• Others– No globally-routable network interface name
• Potential impact on SNMP MIBs– A few legacy apps might remain problematic
• e.g. ftp– DNS reliance is not new, but is more explicit
45heeyoung, ETRI
Critique
• Deployment incentives and benefits?• How communication can be established if a node
is sufficiently mobile?– If moving faster than the DNS update, then DNS fetch
cycle can effectively propagate changes?
• Presume that all communication is tied to DNS names– Some can be done with an explicit ID/LOC pair
• How to determine which LOC pairs (local, remote) are actually functional?– ICMP is insufficient
46heeyoung, ETRI
Rebuttal
• Eliminates the need for PI addressing and encourage increased DFZ aggregation– Can be the incentive for the deployment
• Enables both host- and site multi-homing• INLP mobility eliminates DAD
– ICMP LU separately reduce the layer-3 handoff delay– High mobility problem is the same in MIP
• Deployed IP nodes can track reachability via existing host mechanism or by Shim6
47heeyoung, ETRI
LISP vs. ILNP-(1)
48heeyoung, ETRI
Saleem Bhatti, “ILNP: a whirlwind tour,” 2010
LISP vs. ILNP-(2)
49heeyoung, ETRI
Observations from RFC6115
• RFC6115 is Internet leading group's thought on FI– May be one of big streams for FI– More practical, near-term than NSF architecture related
pojects– IETF is doing and/or like to do related works in near future
• Note that ID/LOC split is not only the solution for scalability but also the one for mobility– Mobile IP is also a sort of ID/LOC split (ID:HoA, LOC:CoA)
• Mobility should be considered together at initial design stage, not as a patch-on
• MOFI(www.mofi.re.kr) pursues this approach
• In conclusion, ID/LOC split seems a promising arch for FI
50heeyoung, ETRI
Warp Up
• FI will mark a new era in ICT– Internet is already a social infra and FI is expected to replace it– Many researches are on-going in US, EU, and Japan but no
consensus yet– A golden opportunity for Korea to jump over the barrier in
current Internet
• Many issues…,but scalability seems the most imminent one– RRG addresses this issue and RFC6115 is a valuable material
for scalability– We had seminar on this document
(http://protocol.knu.ac.kr/MOFI/ts.html)
• Relevant Important technical issues can be discussed in FIF– Join Architecture WG
51heeyoung, ETRI
