RSVPMobility Interactions

1
RSVP/Mobility Interactions

• Michael Thomas
• mat_at_cisco.com

2
Overview

• include ltstd.disclaimersgt
• Draft is about 2 years old many dead brain
  cells
• Im hopelessly behind on mailing list
• Quick MIP overview
• Localization Problems with RSVP
• Cross Realm Policy Questions

3
MIP Overview

• First MIP ! Mobility
• Ill talk about MIP because its illustrative,
  other kinds of mobility need to be considered too
• MIP is a protocol which allows a mobile node to
  wander away from its attachment point (ie, the
  thing that subtends its prefix) through the use
  of L3 tunneling
• Home Agent is that attachment point for both
  forward and reverse tunnels
• IPv4 tunnels to a Foreign Agent on the remote
  network
• IPv6 colocates FA into the mobile node
• IPv6 also allows direct mobile node/correspondent
  node communication makes signaling much more
  complex
• Various schemes for localized tunneling for fast
  handovers

4
Typical MIP Packet Exchange
lt- Corr
Home -gt
Home Agent
CN
lt-- Remote Access
AGG
data
AR1
AR2
5
Real Time Real Pain

• MIP/RSVP should work adequately where loss is
  tolerable
• Speed of light is not our friend
• Restoration of reservations after move requires
  round trip(s) from MN-gtCN for MN rx
• Distance from MN-gtCN is arbitrary
• 100ms is an eternity for voice traffic

6
Localization

• What we really need for RT traffic is to localize
  signaling during handovers
• That is, topology changes need to heal close to
  the mobile node and not touch far nodes not
  involved
• For RSVP this is problematic as a change of CoA
  requires brand new reservations in both
  directions
• Would be nice to not tie reservation to src
  address
• Interesting question for MIPv6 of whether to use
  HoA or CoA

7
More Localization

• Worse, even if you could reuse the same
  reservation, no way to heal the CN-gtMN
  reservation without signaling to the CN
• MN-gtCN could be heal with a PATH from MN to a
  local join point
• No such thing as naked RESVs and the join point
  is clueless that it should issue a new PATH
• Lastly route flap damping protection is at odds
  with fast convergence
• I believe that RSVP sez to wait 100s of ms not
  good
• How does an interior node know that its a move
  rather than a possibly flapping route?

8
Cross Realm Policy

• Everybodys Problem Nobodys Solution
• RSVP Identity (2752) is pretty enterprise
  oriented (eg single domain)
• Not clear whether policy is meant to be e2e or
  hop-by-hop
• Both have tradeoffs
• Worse its not clear that it matters all the
  time
• In many cases, there will be no cross realm
  relationship.
• In that case, RSVP might needlessly cease to work
  for policy reasons
• The net effect is that local loop QoS is pooched
  for no good reason

9
Conclusion

• RSVP has much to recommend it
• Much work over many, many years
• If I hear one more context-free RSVP doesnt
  scale, Im going to smack them in the gob
• It seems quite possible that many of these issues
  can be resolved within RSVP itself
• Some issues are more architectural in nature
• End to end vs end to middle, etc