Partly-Decoupled Signalling in NSIS draft-hancock-nsis-pds-problem-03.txt Robert Hancock, Cornelia Kappler, Juergen Quittek, Martin Stiemerling IETF#65 – Dallas March 2006

Outline Document started as a very broad problem statement draft in 2005 Has benefited from some critical input on/off list Has metamorphosed into a solution based on a mode of use of GIST Content would be appropriate for an applicability statement This discussion covers mainly the solution approach Additional background on motivation, related protocol requirements

Overall Design Goal Maximise the amount of the signalling protocol stack that may be relocated off the forwarding nodes, … while retaining the automatic coupling to topology that the path-coupled approach provides, and compatibility with pure path-coupled approach. Note: The following discussion applies primarily to the GIST path-coupled MRM; but the technique is general

Technical Approach GIST is divided into two parts The Query Message Is responsible for coupling to topology, including rerouting detection/repair Everything Else Including other D-mode messages and C-mode Is responsible for signalling data transport and security We route the Query message as normal But allow it to be backhauled away from path, taking the “Everything Else” with it

Example 1: Leaving the Path Response message payloads control route of signalling (NSIS) data Separate protocols operate between off-path node and forwarding node | NSLP | Messaging association ##########################>>| GIST | # | C/D-mode | #. GIST-Response #. ^ * | NSLP | #.. * #.. * | |<<##########.. V | GIST | | C/D-mode |< GIST-Query |. GIST | | | D-mode| | IP | | IP | | IP | | IP | |Forwarding| |Forwarding| |Forwarding| |Forwarding| > > = Data flow (and direction) > = GIST D-mode messages (and direction) > = GIST C-mode messages (bidirectional) *********> = Control (off-path node to router)

Example 2: Rejoining the Path Query message is re-injected along data path Response message is backhauled so off-path node knows how to initiate signalling connection | NSLP | Messaging Association | GIST |<<########################## | C/D-mode | # # *. ^ # *.. # *.. # |Signalling| V.. # | Appl. | # |..| GIST-Response ##########>>| | | GIST | GIST | |D-mode. | GIST-Query | C/D-mode | |...| >| | | IP | | IP | | IP | | IP | |Forwarding| |Forwarding| |Forwarding| |Forwarding| > > = Data flow (and direction) > = GIST D-mode messages (and direction) > = GIST C-mode messages (bidirectional) *********> = Control (off-path node to router)

Supporting Functionality 1: Intercept Query/Response messages at on-path nodes and backhaul them Interception criterion is precisely ‘UDP packets for destination port=GIST’ Backhaul could be anything (GRE, …) 2: Make the forwarding node do something interesting COPS-PR, SNMP, …

Motivations Minimal functionality needed in on-path nodes  good for legacy node support Control plane processing can be freely located  scale it independent of forwarding; parallelise/coordinate computations for several nodes along a path Could include AAA or resource management algorithms Eased interworking with non-NSIS-like signalling architectures Note: this is not an attempt to bring those architectures into the IETF …

What Next? Would like the working group to adopt this work Can push to completion in fairly short timescale Subject to WG consensus of course Goal of document is an applicability statement for GIST