NSIS in an off-path world –the control plane

Hannes Tschofenig

Robert Hancock

IETF 64

Status

• NSIS was designed to focus on path-coupled signaling– but the design separates discovery from message

delivery.– and the design allows many applications

• If you would like to use an off-path or a control plane solution then you could use NSIS in the subsequently described way:

<draft-hancock-nsis-pds-problem-01.txt>

Example QoS Control Plane – Intra-Domain

Trigger

ResponseRequest

Request Request

Vertical Protocol(e.g., QoS NSLP with different QoSMs, RMD, Y.1541)

Horizontal Protocol

• Horizontal protocol depends a lot on the direction and the purpose, such as Diameter, RADIUS, SNMPv3, etc.

Example QoS Control Plane – Inter-Domain

• Conceptually, the existing discovery procedure just learns the next NSIS-aware device along the path.

• Control messages may take a zig-zag path

Query

(1) Trig

ger

(1) Query

(2) Trigger

Query

Conclusion• The NSIS protocol suite, as a generic signaling solution, is

well-suited for a number of environments and usage scenarios

• Advantage of using NSIS (for the scenarios we investigated):– For intra- and inter-domain signaling reuse QoS signaling and

authorization work– Intra- and inter-domain signaling is can use the same signaling

protocol (it is just QoS signaling along a number of nodes)• Discussions about NSIS usage in the ITU-T and ETSI-

TISPAN in progress (as candidates for off-path signaling usage)– If we engineer it for DiffServ properly then the engineering will be

right. • How are the DCPEL problem statements and requirements

consistent with this discussion?

Acknowledgments

• We would like to thank the following individuals for contributing to this talk:

– Attila Bader – Xiaoming Fu– Georgios Karagiannis – John Loughney– Allison Mankin– Jukka Manner