IRTF RRG Activity
for Future Internet
Heeyoung JUNG
ETRI
Email: hyjung@etri.re.kr
Outline
•
•
•
•
•
Internet and why Future Internet?
IRTF and RRG Overview
RRG Documents
LISP and ILNP
Wrap Up
heeyoung, ETRI
2
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
heeyoung, ETRI
3
Basic Concepts
• Hourglass model
• End-to-End argument
Intelligent
end host
Various
applications
Common
Thin waist
Apps &
Control
Stupid Network
(just delivery)
Various
underlying
technologies
Apps &
Control
Telecom networks
(beads-on-a-string, dummy terminals/smart network)
heeyoung, ETRI
4
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
heeyoung, ETRI
5
Ossification
Peak ?
Fat waist
heeyoung, ETRI
6
Need Something New
Internet
(Clean-slate)
Future
Internet?
heeyoung, ETRI
7
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
heeyoung, ETRI
8
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
heeyoung, ETRI
9
Any Conclusion for FI?
• Seems NO
DTN
• A golden opportunity for Korea to contribute our ideas
heeyoung, ETRI
10
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
heeyoung, ETRI
11
IRTF RGs
• Research Groups
1. ASRG: Anti-Spam Research Group
Security
2. CFRG: Crypto Forum Research Group
3. DTNRG: Delay-Tolerant Networking Research Group Wireless
4. HIPRG: Host Identity Protocol Research Group
Scalability/Mobility
5. ICCRG: Internet Congestion Control Research Group
Transport
6. MOBOPTS: IP Mobility Optimizations Research Group
7. NMRG: Network Management Research Group Management
8. P2PRG: Peer-to-Peer Research Group P2P
9. RRG: Routing Research Group
10. SAMRG: Scalable Adaptive Multicast Research Group
11. TMRG: Transport Modeling Research Group
12. VNRG: Virtual Networks Research Group Virtualization
heeyoung, ETRI
12
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.
heeyoung, ETRI
13
BGP RT Explosion
• The most imminent problem of Internet
Size of
current
BGP FIB?
heeyoung, ETRI
14
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)
heeyoung, ETRI
15
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
heeyoung, ETRI
16
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
heeyoung, ETRI
17
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, …
heeyoung, ETRI
18
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
heeyoung, ETRI
19
Priority
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
heeyoung, ETRI
20
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
heeyoung, ETRI
21
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
heeyoung, ETRI
22
Brief Summary –(1)
• ID/LOC split schemes: makes LOCs topologically aggregatable
No.
Ideas (Author)
Features
1
LISP (Cisco, US)
- Edge-Core network separation (EID-RLOC)
- Various mapping systems(e.g. LISP-ALT,-TREE,-MS,-DHT)
2
RANGI (Huawei,
China)
- Hierarchical 128 bit Host ID and Locator (HIP-like)
- Hierarchical DHT-based mapping system (ID:LOC)
3
GLI-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)
4
Name Overlay Service - Add a name overlay (NOL) onto TCP/IP stack
(Tsinghua Univ.,
- Initiating and mapping transport connection channel by
China)
name
5
Name Based Socket
(SICS, Sweden)
Apps initiate and receive communication session based
on domain name(e.g. ietf.host.org) instead of IP address
6
ILNP (University of St
Andrews, UK)
- 128bit IPv6 address --> 64bit LOC + 64bit ID
- Dynamic DNS as ID:LOC mapping system
heeyoung, ETRI
23
Brief Summary –(2)
• Cont’d
No.
Ideas (author)
Features
7
IRON-RANGER
(Boeing, US)
- Edge (EID) and Transit (RLOC) separation
- Mapping system is similar to global DNS
8
- Regional unique endpoint locator (ELOC) and global
hIPv4 (First Principles, unique area locator (ALOC)
Australia)
- 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)
heeyoung, ETRI
24
Brief Summary –(3)
• Effective mapping systems for ID/LOC split
– Mostly related to LISP
No.
Ideas (author)
Features
EEMDP (NIST, US)
- Mapping distribution protocol for LISP
- ETR’s regional Mapping Server (ILM-R) pushes
mapping information toward ILMs for quick response
2
IvIP (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
3
Two-phased mapping
(unknown)
- Introduce an AS # in the middle of prefix:ETR mapping
- Prefix:AS# (Phase I) and AS#:ETRs (Phase II)
4
Compact routing
mechanism (NSN)
- Dynamic topology adaption to facilitate efficient
aggregation (landmark based routing)
- Map servers as cluster heads or landmark
5
Layered mapping
- Hierarchical mapping system
system (Tsinghua Univ.) - Bottom: EID-LOC, Upper: indexing EID (/0, /16, /24, …)
1
heeyoung, ETRI
25
Brief Summary –(4)
• Other approaches
No.
Ideas (author)
Features
1
Evolution (UCLA)
- Optimization of routing table size by enhancing
aggregation
- Cooperation b/w routers or introducing virtual router
concept
2
Renumbering (IAB)
Change IP addressing information associated with a
host or site
heeyoung, ETRI
26
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
heeyoung, ETRI
27
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
heeyoung, ETRI
28
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
heeyoung, ETRI
29
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)
heeyoung, ETRI
30
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
heeyoung, ETRI
31
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
heeyoung, ETRI
32
Data Plane
Source: David Meyer, “LISP, What Is It,
And How Much Of It Is Real?” 2008
PI EID-prefix 1.0.0.0/8
PI EID-prefix 2.0.0.0/8
ITR
Provider A
10.0.0.0/8
S1
S
ETR
Provider X
12.0.0.0/8
D1
ITR
ETR
S2
Provider B
11.0.0.0/8
D2
Provider Y
13.0.0.0/8
1.0.0.1 -> 2.0.0.2
1.0.0.1 -> 2.0.0.2
11.0.0.1 -> 12.0.0.2
11.0.0.1 -> 12.0.0.2
1.0.0.1 -> 2.0.0.2
DNS entry:
D.abc.com A 2.0.0.2
EID-prefix: 2.0.0.0/8
Legend:
EIDs -> Blue
Locators -> Red
D
Mapping
Entry
1.0.0.1 -> 2.0.0.2
Locator-set:
12.0.0.2, priority: 1, weight: 50 (D1)
13.0.0.2, priority: 1, weight: 50 (D2)
heeyoung, ETRI
Policy controlled
by destination site
33
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 MapRequests
– 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
heeyoung, ETRI
34
LISP-ALT Operation
EID-prefix
240.0.0.0/24
ITR
?
11.0.0.1 -> 240.1.1.1
11.0.0.1 -> 240.1.1.1
240.0.0.1 -> 240.1.1.1
240.0.0.1 -> 240.1.1.1
?
< - 240.1.0.0/16
ALT-rtr
ALT-rtr
?
240.0.0.1 -> 240.1.1.1
ETR
EID-prefix
240.1.1.0/24
ETR
EID-prefix
240.1.2.0/24
240.0.0.1 -> 240.1.1.1
ITR
Legend:
ALT-rtr
ALT-rtr
ALT-rtr
EIDs -> Blue
ALT-rtr
Locators -> Red
ALT
GRE Tunnel
ETR
Low Opex
11.0.0.1 -> 1.1.1.1
Physical link
240.0.0.1 -> 240.1.1.1
Data Packet
Map-Request
Map-Reply
EID-prefix
240.2.1.0/24
?
1.1.1.1 -> 11.0.0.1
Source: David Meyer, “LISP, What Is It,
And How Much Of It Is Real?” 2008
heeyoung, ETRI
35
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
heeyoung, ETRI
36
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
heeyoung, ETRI
37
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
heeyoung, ETRI
38
Naming: IP vs. ILNP
Saleem Bhatti, “Naming for Networking,” 2008
e.g.‘marston.cs.st-andrews.ac.uk’
heeyoung, ETRI
39
Address: IPv6 vs. ILNPv6
• ILNPv6 splits the IPv6 address in half
– Locator (L): 64-bit name for the sub-network
– Identifier (I): 64-bit name for the host
Saleem Bhatti, “Naming for Networking,” 2008
heeyoung, ETRI
40
Header Format
Source
address
Destination
address
Saleem Bhatti, “Naming for Networking,” 2008
heeyoung, ETRI
41
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
heeyoung, ETRI
42
ILNP Session Setup
Avinash Mungur, “Analysis of Locator Identity Split Protocols
in Providing End-host Mobility,” Lancaster University
heeyoung, ETRI
43
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
heeyoung, ETRI
44
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
heeyoung, ETRI
45
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
heeyoung, ETRI
46
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
heeyoung, ETRI
47
LISP vs. ILNP-(1)
Saleem Bhatti, “ILNP: a whirlwind tour,” 2010
heeyoung, ETRI
48
LISP vs. ILNP-(2)
heeyoung, ETRI
49
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
heeyoung, ETRI
50
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
heeyoung, ETRI
51
Thank you!
Heeyoung JUNG
hyjung@etri.re.kr
heeyoung, ETRI
52