1 / 14

MIDCOM Protocol Semantics Overview for Improved Communication Efficiency

Learn about the Semantics overview, the current status, key issues such as PRR transaction, behavior, group transactions, and more. Discover the need for PRR, the behavior of return values in PER, splitting PER, queuing models, and capability exchange during Session Establishment.

saniya
Download Presentation

MIDCOM Protocol Semantics Overview for Improved Communication Efficiency

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. MIDCOM Protocol Semantics55th IETF Martin Stiemerling, Juergen Quittek, Tom Taylor {stiemerling|quittek}@ccrle.nec.de taylor@nortelnetworks

  2. Outline • Semantics overview • Status • Issues: • Why PRR transaction? • PRR behaviour • Group transactions • Address and port wildcarding • Return values in PER • Split PER • Queing model for incoming messages • Capability exchange on Session Establishment • Other open issues

  3. Semantics overview • Same transaction set for all middlebox types • Agent doesn‘t need to know middlebox type • Agent assumption: Twice NAT with packet filter (worst case) • First come first serve • Atomic transactions • Keep it simple, stupid

  4. Status • Stable defintions: • Session control • Policy rule control • To be discussed/under construction • Group control • Prototype implementation done: • Implement complete semantics • Based on SIMCO protocol (draft-stiemerling-midcom-simco-02.txt) • Currently based on ASCII encoding • Upcoming version based on XML encoding

  5. Why PRR? – The Problem • PER used for policy rule establishment • Need address/port mapping before complete 5-tuple is known to MIDCOM agent • No PER possible in this case • But may have only destination‘s parameters (IP address, port number, protocol type) • Example SIP signalling (see next slide)

  6. SIP Telephone UA A SIP Softphone UA B SIP Proxy Middlebox INVITE UA A Listening on: IP_INT,P_INT Need external mapping for IP_INT,P_INT External mapping IP_MB,P_MAP INVITE UA A Listening on: IP_MB,P_MAP 200 OK...

  7. PRR behaviour • Traditional NAT • Allocate only external mapped address/port • Twice NAT – two choices: • Allocated only external mapped address/port • Allocated external and internal mapped address/port • Any case known where both mapped adresses/ports are need during PRR times?

  8. Group transactions • Currently: • Groups are created explictly • New proposal • Groups are created implicitly by PRR or PER • Impact on group transactions • GE and AGD can be dropped • GLC, GL and GS are kept • Default group can be dropped • No group lifetime • Group state machine can be dropped

  9. Wildcarding • Several middlebox scenarios: • Packet filter • Traditional NAT • Twice NAT • NAPT • Different protocols • IP • TCP/UDP • Several combinations result in different wildcarding requirements

  10. Return values in PER • What to return in PER inside and/or outside address/port not allocated • E.g. Packet filter middlebox • Traditional NAT (only outside address/port) • First choice: Return empty/NONE marker • Middlebox type no longer transparent to agent! • Second choice: Return external and/or internal endpoint addresses/ports

  11. Split PER • Currently PER for state transistions: • RESERVED->ENABLED • PRID UNUSED->ENABLED • Split into two • PER1 (RES->ENA) • PER2 (UN->ENA) • PER1 and PER2 need different parameters

  12. Message Queing • Is it required to add a first come first server message processing in section 2.1.2 „Atomicity“?

  13. Capability Exchange on SE • Proposed capabilities: • Type of middlebox • Wildcard support • IP version • Supported optional transactions • Policy rule persistency • Maximum policy rule lifetime • Name of the default group • All needed? • Any other required?

  14. Other open issues • Seperate IP protocol version and transport protocol type in PER/PRR? • Currently IP4/IP6/UDP4/UDP6/TCP4/TCP6 • Need to support ICMP, IGMP, RSVP, ... • Encryption method • In SE transaction • Should SE failure reply convey supported methods • Futher elaborated security considerations • Any other issues?

More Related