resilience issues in information centric networks ning wang ([email protected]) university of...
TRANSCRIPT
Resilience Issues in Information Centric Networks
Ning Wang ([email protected])
University of Surrey
What Happens to Host-to-host Model?
No time-separation: Destinations are not affected by failure if they are not “online” (i.e. no communication sessions)
Location dependence: In case of network failure, repairing routers know how to reach affected destinations via alternative routes
Common practice: make-before-break – e.g. IP/MPLS FRR
© COMET 2011Slide 2
Source Destination D
R1
R2
R3
Backup path available to D via
R3
What Happens to ICN Model?
Failure of additional entities: Rendezvous points, resolvers etc. in addition to routers in the H2H model
Time-separation due to pub/sub: Failures may affect content consumption even after they are recovered
Failures occur during publication phase
Failures occur during resolution phase
Failures occur during delivery phase
Location independence: In case of network failure, repairing routers may not know how to reach affected end users via alternative route
What Happens to ICN Model?
Based on gossip-like content resolution mechanisms
Failure during publication
Failure during resolution
Failure during delivery
Publish(C1) – failed! Resolve(C1) – failed!
Failure Recovered
Publish(C1) – success! Resolve(C1) – failed!
Normal Failure
Publish(C1) – success! Resolve(C1) – success!
Normal
Delivery(C1) – Failure!
FailureNormal
Illustration with COMET Couple Approach
Target: Protection against rosolver (CRME) failures during content publication/resolution phase (assuming no backup CRME in the same domain)
© COMET 2011Slide 5
CRME 1 CRME 3
CRME 2
Content consumer
Content server S
Content resolution path
Content delivery path
X: Incoming = 1.2.0.1 Outgoing = {1.0.0.1}
0.10.0.20.0.1
S: X
Proposed Scheme
Bootstrap phase
- Each CRME disseminate reachability information about its immediate provider CRME(s) to its other CRMEs
- Each CRME knows its counterparts two-hops-away
Publication/Resolution phase
- In case the immediate next-hop CRME becomes unavailable, the current CRME directly forwards the content publish/consume request to its next-next-hop with a tagged flag indicating the bypass of the middle failed CRME
CAFE configuration (resolution phase only)
- A CRME that receives a request with tagged flag needs to configure its local CAFE pointing to the ingress router of the remote domain from where the remote CRME sent that request
© COMET 2011Slide 6
Bootstrap
Operation: Reachability information dissemination across CRMEs
© COMET 2011Slide 7
CRME 3
CRME 2
1.1/16
1.1.1/24
CRME of my provider = “CRME1”
CRME 1
1/8
• In case CRME 2 becomes unavailable, CRME 3 will be able to directly contact CRME 1 for content publication/resolution
Tier 1
Tier 2
Tier 3
1.0.0.1
Content Publication
Intermediate CRME becomes unavailable during publication
© COMET 2011Slide 8
CRME 3
CRME 2
1.1/16
1.1.1/24
CRME 1
1/8
• In case CRME 2 becomes unavailable, CRME 3 will be able to directly contact CRME 1 for content publication/resolution
Publish(1.1.1/24, X1)
S1: X1
X1->S1
X1->1.1.1/24
Tier 1
Tier 2
Tier 3
1.0.0.1
Content Resolution (based on post-failure publication for the content)
Even when CRME2 has been recovered, it still misses the previous content publication for X1, so CRME1 still needs to bypass it
– CONSUME message should include IP address of own ingress CAFE
© COMET 2011Slide 9
CRME 3
CRME 2
1.1/16
1.1.1/24
CRME 1
1/8
S1: X1
X1->S1
X1->1.1.1/24
Tier 1
Tier 2
Tier 3
CONSUME (X1)
CONSUME(X1)Ingress: 1.0.0.1
1.0.0.1
X1: Outgoing NH = {1.0.0.1}
Content Resolution Scenario (based on normal content publication)
© COMET 2011Slide 10
CRME 3
CRME 2
1.1/16
1.1.1/24
CRME 1
1/8
S1: X1
X1->S1
X1->1.1/16
Tier 1
Tier 2
Tier 3
X1->1.1.1/24 CONSUME (X1)
• Based on normal content publication operation, content resolution cannot be successful
Content Resolution Scenario (based on robust content publication)
• Solution: robust content publication – to add additional information on NNH towards content source
CRME 3
CRME 2
1.1/16
1.1.1/24
CRME 1
1/8
• CRME2 includes the NNH information for context X1 to its forwarded publish message to CRME1
S1: X1
X1->S1
X1->1.1/16(NNH=1.1.1/24)
Tier 1
Tier 2
Tier 3
1.0.0.1
Publish (X, NNH=1.1.1/24)
Content Resolution Scenario (based on robust content publication)
© COMET 2011Slide 12
CRME 3
CRME 2
1.1/16
1.1.1/24
CRME 1
1/8
S1: X1
X1->S1
Tier 1
Tier 2
Tier 3
X1->1.1.1/24 CONSUME (X1)
• In case CRME1 cannot contact the default next hop CRME2, it is able to send the content request to
the NNH CRME which is CRME3 X1->1.1/16(NNH=1.1.1/24)
CONSUME(X1)Ingress: 1.0.0.1
1.0.0.1
X1: Outgoing NH = {1.0.0.1}
Summary
Resilience in host-to-host based communications with location dependence seems to be more straightforward
In case of ICN (based on gossip-like communications): Failure during different phases (publication, resolution, delivery) may have different impacts on content services
Do we have a holistic resilience protection framework for such ICN environment?
© COMET 2011Slide 13