NTLP Design Considerations draft-mcdonald-nsis-ntlp-considerations-00.txt NSIS Interim Meeting – Columbia University February 2003

Design Issues Things that are normally considered in the transport layer in the Internet layer model Attempt to pose questions neutrally… “Spectre at the feast”: Why not TCP/SCTP? Assertion: given the desired NTLP functions, basic characteristics of NTLP design are pretty well fixed whether you use TCP/SCTP or not Could we make different choices for different parts (e.g. message transport vs. peer discovery)?

Peer Discovery How does peer discovery process relate to the rest of the protocol? Is it performed implicitly as part of the protocol (like RSVP e2e PATH)? Are there a separate discovery messages? Should we make space for other mechanisms? How does an NTLP entity detect that it is the last one before data receiver? What if there are more NSIS nodes but none with appropriate NSLP?

Configuration Discovery How is this information exchanged? Whether particular NSLPs are supported by an NTLP entity What features are supported at NTLP or above What options are supported E.g. transport options, security mechanisms When should it be done (latency issue)? Any guidance from RSVP?

Path Divergence Signalling/data path – if PATH (discovery) packets differ from data flow packets then paths may diverge E.g. where policy forwarding is being used Basic question: non-DA forwarding in intermediate NSIS-unaware routers To what degree should these messages be made to look like data flow? (RSVP makes no effort to do this)

Rerouting Detection How is rerouting of data flow detected? And what is the NTLP response? Attempt path repair itself? Inform NSLPs?

NAT Traversal If we try to make NAT handling of NSIS protocols generic over all NSLPs: Which ‘parts’ of protocol should do it? Certainly impacts initial messages… Can this set things up for rest of session? Or, assume a more stateless model? Will the NTLP be a midcom application?

State Location/Latency Are we optimising for low setup latency? Implies minimised state creation within network (no negotiations, round trips) Or rapid reaction to changes? State must be established within network to trigger and expedite reactions Big list of possible types of state in draft Does the NTLP provide any state merging functions or “lazy forwarding” like RSVP, where changes and refreshes are forwarded differently?

Failure Management Should NTLP be able to detect and handle failures itself? Should NTLP provide a graceful failover method? If not, should it provide facilities to allow easier failover by an NSLP? What should be done to manage rerouting/flapping on NSIS entity restarts? Problem scale depends on sparseness of NSIS relationships – all nodes NSIS-aware is worst case!? Should the NTLP do its own hold-down processing if it handles rerouting events?

Conclusions Fill in protocol design here: (clean sheet)

Additional Backup (General Design Details)

Congestion Avoidance Do we need it? Is it optional? Depends on NSLP? Depends on location? (Core/Fringe?) Should we do it ourselves? (custom to NTLP?) Should we use an existing protocol? (e.g. TCP, SCTP, DCCP) Is head of line blocking a problem? Congestion avoidance just about requires state between known NTLP peers

Message Ordering and Duplication Does message reordering matter? In receiving messages from lower layers (IP) In presenting messages to NSLP Does it depend on NSLP? (e.g. QoS vs MIDCOM) Do we actually want out-of-order delivery? E.g. for latency reasons What about security interactions? Does the NTLP provide duplicate message detection?

Security Message Protection Peer-to-peer at NTLP? Leave end-to-end protection to NSLP? Use existing mechanism (e.g. IPsec, TLS) or roll our own (like RSVP)? Restrictions on addressing model; open-ness to variety of key management mechanisms Denial of Service Protection How much should NTLP reuse existing mechanisms? (e.g. incorporate SCTP cookies, IKE cookies) What mechanisms does NTLP provide to protect NSLP? (e.g. flow control?)

Bundling/Fragmentation Do we need message bundling? Would existing transport protocols provide what is needed? Are their timing rules appropriate? (Do they matter in detail?) NB bundling basically prohibits e2e addressing Do we need message fragmentation? Would existing transport protocols provide what is needed? Can we constrain NSLP message sizes?

Lossless Transport How is message loss identified? Needs sequence # - ack or nack based? Should the NTLP provide: End-to-end reliability (even across concatenated hops)? Or just recovery from ‘most’ losses between NTLP peers (“high probability of delivery”)? Should it even provide explicit delivery confirmation?

Overload Protection Overload may occur For malicious purposes Due to errors Due to traffic levels (congestion or under-performing applications) What mechanisms should the NTLP provide to prevent overload during normal use? In particular, overload of NTLP itself What does it provide as a service to the NSLPs? (e.g. flow control?)

Feedback/Error Messages ICMP – when e2e addressing is used, do errors go to the right/useful place? Signalling and flow endpoints may not be the same What data is useful in ICMP error messages? Are error messages sent back along the path hop-by-hop, or are they directly addressed? When is NTLP state torn down? Is there a distinction between NSLP path teardown and NTLP session termination? Does path teardown remove NSLP reservation state? Any NSLP error service beyond ‘no such application’?

Message Objects and Extensibility Do some objects need to be marked as “optional” or “critical”? RSVP (depending on situation) can reject message ignore object and not forward ignore object and forward send error back leave to appropriate module Becomes bigger issue where there are several applications in use simultaneously…

Message Objects and Extensibility NTLP needs to support New signalling applications New types of signalling application New capabilities Addition optional aspects of a signalling application Does NTLP need to support multiple signalling applications simultaneously? In the same message? Both related to the same ‘reservation’ identifier?