1

Path-decoupled signaling - towards a BOF in SFsven.van_den_bosch@alcatel.be

• NSIS working group context• Path-decoupled signalling - definition

– Path-oriented signaling for which the signaling path doesn’t necessarily coincide with the data path of the signaled flow

– Examples: signaling is not initiated by end hosts, or when signaling is directed to NSIS forwarders that are not on the data path.

– It is not signalling to arbitrary entities in the Internet

• Several people are interested in path-decoupled signalling– Mailing discussions

– Related drafts• Draft-schelen-nsis-opopsig-01.txt• Draft-declercq-vsn-arch-00.txt• Draft-vandenbosch-nsis-resilience-00.txt • Draft-hancock-nsis-fw-outline-00.txt

2

Why path-decoupled signalling?

• It facilitates deployment– Flexibility in signaling entity deployment

– Easier migration path for early adopters

– Allows continued use of legacy equipment

• It is a useful alternative when a ‘path’ is not a stable concept– Mobility: context transfer, seamless handover

– BGP route changes

• Some product implementations are already available– Risk for incompatible solutions

• It simplifies interworking with domains applying forwarding planes other than IP or using private addressing schemes.

• More arguments are documented in draft-schelen-nsis-opopsig-01.txt

3

Path-decoupled signalling does raise some concerns …

• Addressing– Comparison to what is being proposed in the BGP community may

be helpful

– We are still talking about path-related signalling not signalling to arbitrary entities

• Self-healing properties– Path-decoupled signalling is likely to be focused on QoS

• IGP/BGP convergence times may not be sufficient for some services

– Data plane and control plane cannot be assumed to share fate• Resilience will be an important issue

• Security– Path-decoupled signalling is not necessarily harder than path-

coupled signalling but it poses different security issues• additional security threat classes should be investigated

4

… and requires some additional issues to be solved

• Determination of next control plane hop– It does not necessarily correspond to the next data plane hop

• Alignment with routing tables– Identification of the ingress and egress point in the controlled

domain is required

– Potentially requires knowledge about the route followed between ingress and egress in the domain

5

We believe this work should be done in the IETF

• It may be separated from but should be coordinated with NSIS• It needs to be interoperable with the NSIS solution in order not

to mandate a particular approach along the path

6

What should we focus on?

• Indicate how a path-decoupled solution could be built reusing the NSIS work, addressing the additional issues to be solved– Addressing

– Resilience (fate sharing)

– Security

– Determination of next control plane hop

– Alignment with routing tables

• Provide input to NSIS to avoid decisions from being taken that unnecessarily complicate path-decoupled signalling

• Some topics are explicitly identified as out of scope– NTLP/NSLP separation (NSIS)

– Interaction with routers

– QoS class negotiation