Content-Centric Networking at Internet Scale through The Integration of Name Resolution and Routing J. J. Garcia-Luna-Aceves UCSC/Xerox PARC
Overview q Routing to names is not better than routing to addresses in a content-centric network q Implications: Limitations of NDN and CCNx q CCN-RAMP: CCN based on routing to locations of name prefixes q Performance comparison of CCN-RAMP and NDN
Is Routing to Names Better than Routing to Addresses? q A name may have multiple instantiations (multi-homing of names) S 2 m k z c 1 A*, C*, P* q A route can exist only between an instantiation of a source and an v n y r instantiation of a destination S 1 p u w q e.g. , route from E to B or from E to A in P*, Q*, R* c 2 the example S 3 q What does “routing to names” imply? A*, C*, Z* q What advantages does it provide vs. routing to addresses? q How much does it cost? q Is it a good tradeoff? Do benefits justify the cost?
What Routing to Names Implies q No name-to-address mapping by special servers q Name resolution is done at the same time as routing at each hop along the path from consumer to site advertising a name prefix q Benefits: § No long delays due to DNS, no user or application involvement in name resolution, … q Cost: Name resolution and routing § Very large FIB at each router; all name prefixes must be listed § A large PIT to keep reverse routes § At least two orders of magnitude more complex than table lookup in IP routers: e.g., > 10 8 registered domains Each forwarding router < 10 6 IP address ranges being routed is a name resolver!
Routing to Names vs. Routing to Their Locations q Same routes! PATHS FROM ROUTING TABLES S 2 q More entries must be m z k looked up using names A*, C*, P* than using addresses v n y r This is important: > 10 8 registered domains S 1 < 10 6 IP address ranges being p u w routed P*, Q*, R* or… { A *, C *, P *}, next = v = y , next = v { Q*, R* }, next = v { P*, Q*, R* }@ y , next = v = y , next = v z , next = v { A *, C *, P* }@ z , next = v z , next = v Routes to all instances of a name Routes to nearest instance of a name
Routing to Names vs. Routing to Their Locations INFORMATION USED IN ROUTING PROTOCOLS: q All name-based content routing protocols provide routing information for both name prefixes and the routers where servers storing content for them are attached [ anchors ] q Link-state protocols: Link state advertisements stating virtual links from anchor to name prefix must be used q Distance-vector protocols: Distance to name prefix uses anchor of name prefix used as a label to avoid permanent loops q Stating an anchor of a name prefix must be done for a route to the name prefix to be valid. q More efficient to send “updates about anchors” and “updates about mappings of names to anchors” separately
Routing to Names vs. Routing to Their Locations ADAPTING TO Assume first router binds name to an anchor; routes NETWORK DYNAMICS are mostly the same even with topology changes D oa j > D oa i = D or + D ra i D oa i r D * New distance from r to a i ra i = S 2 a i after topology change P* c o a j S 1 P* Routing to names can be more efficient only if , i.e., rarely! D * ra i < ∞ ∧ D ra j < D * ra i or D * ra i = ∞ ∧ > D ra j < D ro + D oa j
Routing to Names in NDN/CCNx q FIBs list name prefixes Forwarding Interests to name prefixes does not provide large benefits vs. forwarding Interests to addresses of anchors q PITs list reverse paths towards consumers allowing aggregation Interest aggregation can lead to undetected Interest loops [ ] “Waiting-to-infinity” problem (aggregation and routing-table loops) Opens network to new DDoS attacks (Interest flooding) On-path caching obviates the need for Interest aggregation q PITs support multicasting support w/o multicast routing protocol Can be done without per-Interest forwarding state [ ]
Routing to Names in NDN/CCNx q FIBs list name prefixes § Forwarding Interests to name prefixes vs. forwarding Interests to addresses of anchors render similar paths with more overhead q PITs list reverse paths towards consumers allowing aggregation § Interest aggregation can lead to undetected Interest loops (see [13, 14]) “Waiting-to-infinity” problem (aggregation and routing-table loops) § On-path caching obviates the need for Interest aggregation (see [8] ) § Opens network to new DDoS attacks (Interest flooding) q Multicasting support w/o multicast routing protocol § Can be done without per-Interest forwarding state (see [18]) WHY NOT USE LOCATORS RATHER THAN NAMES FOR INTEREST FORWARDING?
CCN-RAMP: Routing to Anchors Matching Prefixes GOAL 1: ELIMINATE LARGE FIBS S 2 13 101 m k z q Use Interests, data packets and c A*, C*, P* NACKs as in NDN and CCNx 49 v n y r q Have ingress router [attached to consumer] bind name to an “anchor” S 1 p u w (i.e., location of the name prefix) P*, Q*, R* q Forward Interests towards anchors Forwarding routers just do routing • after initial binding to anchors Any content routing protocol can • q Use same routing protocol used in be used NDN/CCNx to populate routes to How do ingress routers function as • anchors and name-anchor mappings name resolvers?
CCN-RAMP: Routing to Anchors Matching Prefixes S 2 13 101 m k z GOAL 2: ELIMINATE UNDETECTED c A*, C*, P* INTEREST FORWARDING LOOPS 49 v n y r q Use distance information in S 1 forwarding tables p u w P*, Q*, R* q Add distance-to-anchor information in Interests Works with any routing protocol • Works under any assumption of topology changes • or forwarding-table inconsistencies Works with or w/o Interest aggregation (i.e., PITs) •
CCN-RAMP: Routing to Anchors Matching Prefixes GOAL 3: ELIMINATE PITS S 2 13 101 m k z q Maintain same level of Interest c A*, C*, P* anonymity as in NDN/CCNx 49 v n y r q Send back COs using forwarding tables that are O(N) S 1 p u w [N is number of routers, rather than P*, Q*, R* number of pending Interests) q Rely on: What forwarding state should • § On-path caching obviates the need for routers maintain? Interest aggregation [8] How can “pseudo-anonymous • § Data-plane multicasting can be done Interest forwarding” be done without per-Interest forwarding state [18] without PITs?
CCN-RAMP q Interest I [ n ( j ), AID I ( k ), a I ( k ), D I ( k )] forwarded by router k states § Content name n ( j ), an anonymous identifier AID I ( k ), § anchor a I ( k ) of prefix for n ( j ), distance to anchor D I ( k ) , q Data packet DP [ n ( j ), AID R ( k ), sp ( j )] forwarded by router k states § Name n ( j ), anonymous identifier AID R ( k ), and security payload sp ( j ) q Three forwarding tables: § PRT (prefix resolution table): Used by name resolvers § FAB (forwarding to anchors base): Used by routers to forward Interests § LSAT (label swapping with anchors): Used to routers to forward COs back q CS (content store) for edge caching or on-path caching q LRT (local resolution table) for handling Interests from local consumers.
Interest Forwarding in CCN-RAMP LRT k : I [ n ( j ), - , - , - ] S 2 I [ n ( j ), 15, z , 2] I [ n ( j ), 53, z , 1] ({consumers}) m z k CO { list } A*, C*, P* c n ( j ) { c, … } … Lists consumers n y v r requesting COs PRT k : S 1 p u w ({anchors}) FAB k : P*, Q*, R* n ( j ) � P* A * { z } LSAT k : { (next, distance)} C * { z } … (prior, MAP, next, distance) y { ( m , 3), ( v , 3) } P* { y, z } z { ( m , 2), ( v , 3) } P* { y, z } z { ( m, 2) 15 15 k , k, 15, m , 2 15, m , 2 z … … 49 r , 101, m , 2 71 r , 139, m , 3 Maps name prefixes Routes to anchors … to anchors at edges Routes back to anonymous sources
Interest Forwarding in CCN-RAMP S 2 I [ n ( j ), 101, z , 2] I [ n ( j ), 72, z , 1] m z k A*, C*, P* c I [ n ( j ), 49 y , 3] n y v r S 1 p u w P*, Q*, R* LSAT k : FAB k : (prior, MAP, next, distance) { (next, distance)} 15 k , 15, m , 2 y { ( m , 3), ( v , 3) } 49 r , 101, m , 2 z { ( m , 2), ( v , 3) } 49 r, 101, m , 2 z 71 r , 139, m , 3 … … Routes to anchors Routes back to anonymous sources
Data Forwarding in CCN-RAMP LRT k : DP [ n ( j )] S 2 DP [ n ( j ), 15] DP [ n ( j ), 53] ({consumers}) m z k A * { z } A*, C*, P* n ( j ) { c, … } c … Lists consumers n y v r requesting COs PRT k : S 1 p u w ({anchors}) P*, Q*, R* A * { z } FAB k : LSAT k : C * { z } { (next, distance)} … (prior, MAP, next, distance) y { ( m , 3), ( v , 3) } P* { y, z } 15 k , 15, m , 2 15 k, 15, m , 2 z z { ( m , 2), ( v , 3) } … 49 r , 101, m , 2 … 71 r , 139, m , 3 Maps name prefixes Routes to anchors … to anchors at edges Routes back to anonymous sources
CCN-RAMP: Preventing Forwarding Loops q FAB maintains next hop and distance to each anchor known by router q S ia = set of next hops to anchor a in FAB i q D i [ AID I ( k )] = distance to AID I ( k ) in LSAT i q D ( i , a , v ) = distance from neighbor v to anchor a in FAB i Rule (ALF): Router i can forward Interest from k if : Closer according AID I ( k ) Ï LSAT i � � v � S i a ( D I ( k ) > D ( i , a , v ) ) to FAB a ( D I ( k ) > D i [ AID I ( k )] ) AID I ( k ) Î LSAT i � � v � S i Closer according to LSAT See Theorem 2 in paper
Recommend
More recommend
