Impact of architecture on requirements draft-schulzrinne-ecrit-mapping-arch

1
Impact of architecture on requirementsdraft-schul
zrinne-ecrit-mapping-arch

• Henning Schulzrinne
• Columbia University
• hgs_at_cs.columbia.edu

2
1 summary

• Seekers
• want information
• Resolvers
• know gt 1 forest guide (but not trees)
• Forest guides (many)
• know trees
• Trees (gt 1)
• have authoritative data for particular regions

3
Multiple actors
EMA draft-schulzrinne-ecrit-mapping-arch

• End users
• just want mappings (EMA seeker)
• may only be connected occasionally
• use different ISPs and VSPs
• Internet service providers
• no inherent interest in emergency services
• but want to make service reliable for their users
• ? EMA resolver

• Emergency service authorities
• (only they) know authoritative data about their
  jurisdiction
• only responsible for small geographic subset of
  the world
• may not be interested in world at large
• hierarchically structured (e.g., country, region,
  county, city)
• ? EMA authoritative servers in tree
• Mapping service providers
• dont have (direct) authoritative data
• but can be (politically) neutral
• can detect colliding claims between different
  trees
• ? EMA forest guides

4
Multiple actors

• High-level architecture requirement accommodate
  competing and non-cooperative parties
• see also Tussle in Cyberspace, by David D.
  Clark, John Wroclawski, Karen R. Sollins, Robert
  Braden
• Division on previous slide just an example
• but seems probable
• some functions could be collapsed into one box or
  omitted in particular deployments
• Different actors have different skills and
  interests
• some may be competing with each other
• ISPs, VSPs, mapping providers
• limited mutual trust or limited ability to
  determine trustworthy parties
• national politics (Oceania is not talking to
  Eurasia) ? need neutral parties
• there may not be a political root organization
• see ICANN difficulties

5
Requirements?

• End user must be able to perform mapping if
  mapping functionality is offered by VSP (or other
  third party), not ISP
• this does not preclude ISP participation!
• Mapping nodes must be able to refer clients to a
  more appropriate node
• that node may be operated by some other entity
• Different resolution hierarchies must be able to
  co-exist
• for different services different regions