Next-Gen Proactive MANET Routing MANET, 62th IETF, Minneapolis, - - PowerPoint PPT Presentation

▶
next gen proactive manet routing
SMART_READER_LITE
LIVE PREVIEW

Next-Gen Proactive MANET Routing MANET, 62th IETF, Minneapolis, - - PowerPoint PPT Presentation

Oct 29, 2023 241 likes •357 views

Next-Gen Proactive MANET Routing MANET, 62th IETF, Minneapolis, 2005 Status Background: experiences from RFC3626, RFC3648, misc I-Ds Design team: vocal implementers/users of proactive protocols Activities thus far:

slide-1
SLIDE 1

Next-Gen Proactive MANET Routing

MANET, 62th IETF, Minneapolis, 2005

slide-2
SLIDE 2

Status

  • Background:
  • experiences from RFC3626, RFC3648, misc I-Ds
  • Design team:
  • “vocal” implementers/users of proactive protocols
  • Activities thus far:
  • gather experience
  • ponder components
  • write design-documents
  • not (yet) draft writing....
slide-3
SLIDE 3

Design “Dogmas”

  • Flexible and extensible where sensible:
  • external extensibility - new message types
  • internal extensibility - add information to existing msgs
  • Unification of concepts/messages:
  • e.g.: OLSR TC, HNA, MID
  • e.g.: OLSR HELLO, MID
  • Maintain/respect IP architecture
  • The “Graduate Student Criteria”
slide-4
SLIDE 4

Design “Dogmas”

  • Keep basic case (e.g. single if/address) simple
  • while supporting complete case (e.g. multi if, multi-

address)

  • Std. track specification will contain:
  • normative for interoperability
  • example algorithms/parameters
  • Based strictly on “known stuff”
  • but accommodating for future extensions
  • Efficiency - but not at all costs
slide-5
SLIDE 5

Basic Protocol Functioning

  • Basic link-state protocol
  • Optimized flooding
  • Local-scoped signaling (HELLOs)
  • topology maintenance (link, neighbor detection)
  • forwarder/relay signaling, etc
  • Global-scoped signaling (TCs)
  • Inject link-state information to all nodes
slide-6
SLIDE 6

Control Traffic

  • Making statements about addresses:
  • “there’s a link between me and.....”
  • “this property is associated with.....”
  • Possible properties:
  • “sym”, “asym”, “cost”, “DR-selection”, “flooding relay

selection”, “security association”....

  • Address block & TLV association
  • inspired by OSPFv2 LLS
slide-7
SLIDE 7
  • Example:
  • {<address-block><tlv1><tlv2><tlv3><tlv4><tlv5>}
  • <tlv> can apply:
  • to single address
  • to sequence of addresses
  • to all addresses
  • to message
  • Unknown TLVs: ignored

Address Block & TLV

E.g.: OLSR HELLO message TLVs: SYM, ASYM, MPR

slide-8
SLIDE 8

Addresses

  • An address is a sequence....any sequence...of

bits

  • IPv4 - 32bit, IPv6 - 128bit
  • other lengths: bluetooth, sensor, ...
  • Most nodes share the same, long, prefix
  • Flexible, compressible address

representation: address-block

  • {<address-length><head-length><head>{<tails>+}}
slide-9
SLIDE 9

IPv6 support

  • More than just longer addresses:
  • multiple addresses/node: the norm
  • link-local addresses:
  • useless in MANETs
  • not advertised or routed
  • supported for IPv6 “legacy” support
  • unique local addresses, global addresses
  • advertised & routed within MANET
  • no advertisements outside MANET
slide-10
SLIDE 10

Tasks & Thoughts

  • Simplify multiple address/interface case
  • Possible separation between flooding relay &

“DR” designation

  • Support for different msg. interval models:
  • exponential backoff, periodic, fuzzy/fsr, ...
  • Support for != mandated behavior
slide-11
SLIDE 11

Near-term schedule

  • -00 draft: ~2-4 weeks after IETF
  • compilation of design-doc’s
  • well-iterated by design-team
  • Possible informal documents (I-Ds ?):
  • design rationales / considerations
  • best practice
  • “exotic extension X implemented thus....”