1. Design Considerations for the Common MIH Protocol Functions draft-hepworth-mipshop-mih-design-considerations-01 Ele Hepworth (*), Robert Hancock, Srinivas Sreemanthula, Stefano Faccin November 2006 IETF#67, San Diego (*) Robert Hancock as a stand-in

2. Where does this draft fit in?

3. Draft Structure and Contents “MIH Common Protocol Functionality” (this draft) is what is called “Mobility Service Transport Protocol” (in the problem statement, compare figure 5) –MSTP is a catchier name, but need to bear in mind that the solution is not necessarily a single protocol, and the problem is not only transport The total ‘interesting’ length is ~15pp –Your comments will be appreciated

4. Activity since the -00 Version Some limited discussion on design issues More discussion about particular solutions and their characteristics –We have tried to reflect the underlying issues in this DC draft in a solution-neutral way GIST also presented “for information” at IEEE 802.21 meeting in Melbourne –Again, tried to capture the underlying aspects in this revision Short version: a set of minor tweaks, and new material on issues with the discovery process and what has to happen when the signalling peer changes

5. Problem Boundary Issues Thinking more about the design of the common part  possible fine tuning of the layer boundary location Signalling peer identification –Does the “MIH service” (i.e. MSTP user) identify the signalling peer implicitly (and if so, in which identifier space) or explicitly (e.g. with an IP address)? –How are the individual “sub-services” themselves distinguished For example, is “802.21” an MSTP user, or is “802.21/ES” an MSTP user? MIH state management –The MIH may need to refresh, tear down, modify state in a peer – does the common part know about these distinctions or just move data around? –Current working assumption: all of this is decoupled between the two layers Multiparty operation –If there are signalling ‘chains’ (proxy operation), does the common part see the whole chain or just adjacent nodes? –Current assumption: this is not an issue for the MSTP – it should only see direct peering relationships. It is possible that even the MIH service protocols will only refer to direct peering relations, and proxying is an implementation choice [All these have knock-on effects for the functionality inside the ‘black box’ as well]

6. Routing and Discovery Several key points identified: –What criteria must be used in the discovery process –What identifier spaces to express these criteria in –How to include capability aspects Linkage to other common protocol functions The ‘what criteria’ question interacts with the question of what discovery/capability negotiation takes place within the MIH service itself –E.g. who selects between ES/IS/CS, how service version number selection takes place Defines some major architectural options –Full MN control –Discovery details delegated to the network –Discovery of adjacent peer or full path Issues for each: deployability, topology hiding, timing w.r.t. network attachment, operation in mixed L2/L3 environment Discusses some options and their issues –SLP, DNS SRV, mDNS, DHCP, RA Current status: this is still the major unclear issue –Ad hoc discussions this week, we will try to capture and write them up

7. Transport Functions Discusses major functions required, e.g. –Congestion control –Reliability –Large message handling Believe that all of these are needed for at least some elements of MIH support –Note: reliability/congestion support relates to high-performance (rapid/adaptive) handling of network layer packet problems –Assumes simple/robust handling of MIH service problems above the common part –Defining a signalling transport without intrinsic congestion control for the bulk of the traffic is probably a non-starter in the IETF Identify some options for designing the support: –Rolling your own (highly undesirable) –Re-use of existing transport protocols

8. Security Identifies some broad security issues to be considered –How to analyse the mixed L2/L3 case –What it means to secure the discovery process Baseline assumption: MIH support will provide a channel security service and make authenticated peer identities available to MIH services –Assumption of re-using standard security protocols –Protocol selection depends on deployment issues –MIH security analysis can only be done on the completed solution (including the MIH service itself) Note: the major work that will have to be done (in mipshop) is to define the rules/policies for invoking the channel security protocol –E.g. for TLS: what sorts of names should be used in TLS certificates –What sort of attributes one should demand/expect in those certificates

9. Conclusions We’d like to offer the draft: –In the short term – as a mechanism to capture community expertise on protocol design gotchas at an early stage in the process –In the long term – as a means to record the fundamental reasons things were done one way rather than another Although this version clarifies that we assume the draft won’t be a published WG milestone Please send us your thoughts!