200 likes | 330 Vues
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…
E N D
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?