1. MONET Problem Scope and Requirements draft-kniveton-monet-requirements-00 T.J. Kniveton Alper Yegin IETF 53 21 March 2002

2. 2 © 2002 Introduction These requirements are based on terminology in Ernsts terminology draft and further discussions on MONET list Changes from other drafts: – No distinction between local and visiting MNs, or local fixed router – Main entities: FH, FR, MH, MR, MN View on requirements may be simplified but compatible with other requirements drafts – We are focused on solving IPv6 mobile network problems based on actual members requirements – We look at MIPv6 as a good starting point, and favor analysis of other protocols to exclude aspects already solved in other contexts

3. 3 © 2002 Problem Scope Primary goal to allow MNNs to remain connected to the Internet and continuously reachable while MONET moves MNNs could be either fixed on MONET, or mobile Secondary goals to investigate effects of network mobility on MNNs communications – Routing protocol changes – Realtime traffic and fast handovers – Other optimizations and service aspects Since this is within IETF purview, focus should remain on implementation-oriented solutions. Research can be redirected to IRTF and other appropriate venues

4. 4 © 2002 Non-goals Host mobility (MIP) Administration of Network Address Assignment Network Architectures (this may be open to discussion) Service discovery solutions Complicated abstract architectures

5. 5 © 2002 Security MR has unique characteristics: security may be a hybrid of host and router – In subscriber case, MR may have limited power such as being delegated a prefix – MR may be part of trusted routing fabric Trust relationship between MR and nodes on mobile network – Should be similar to fixed network R/N trust

6. 6 © 2002 Protocols IPv6 is basis for defining mobile networks – IPv4 is not excluded from scope – but IPv6 is the requirement Mobile IPv6 is probably the best starting pt – Already solves host mobility – Extensions should provide simplest path to achieve goals of MONET Routing and addressing changes Route optimization is desirable but secondary P.S. there are proposed solutions and implementations for MONET, but..lets not talk about that yet

7. 7 © 2002 Architectural Suggestions Supporting nesting is desirable Transit networks are excluded – To keep clear distinction from MANET Multi homing is allowed Infrastructure-less route optimization is desirable but secondary – security issues need to be solved first

8. 8 © 2002 A Network MNFN Rtr AR1 Fixed Internet. This is not a MANET.

9. 9 © 2002 MONET Should Solve: AR2 A network Using a prefix. MR AR1 MONET solves the area in the green blob -How can a router traverse the fixed infrastructure and bring a static, semi-static, or dynamic subnetwork with it, so that packets still arrive for that net? Fixed Infr.

10. 10 © 2002 A MONET 1 AR2 MNFN Rtr MR AR1 A moving network. The nodes in the network do not need to be aware that its point of attachment to fixed topology has changed. This is still not a MANET. (For the same reason Mobile IP is not a case of MANET). Fixed Infr.

11. 11 © 2002 A MONET 2 AR2 MR AR1 The MR is routing to nodes inside its moving network, which happen to be communicating with eachother using MANET proto. MRs association with the fixed infrastructure and movement of MANET prefixes still not a MANET. MANET Fixed Infr. MaR (This slide wasnt presented during MONET BOF)

12. Thank you. draft-kniveton-monet-requirements-00 T.J. Kniveton Alper Yegin