1. Reliable PIM Registers draft-anish-reliable-pim-register
Targeted Hellos
Targeted Hellos
Targeted Hellos
IETF93: Prague • • • • • •
IETF93: Prague
IETF93: Prague
IETF93: Prague • • •
IETF93: Prague
IETF93: Prague • • • • • • • • • • •
IETF93: Prague •
IETF93: Prague • • • • • • • • • • • • •
IETF93: Prague • • •
IETF93: Prague • • • • •
IETF93: Prague
IETF93: Prague • •
IETF93: Prague • • •
IETF93: Prague • • • •
IETF93: Prague • •
IETF93: Prague
IETF93: Prague •
IETF93: Prague • • • • • • • • • • •
IETF93: Prague • •
IETF93: Prague
IETF93: Prague • • • •
IETF93: Prague • •
IETF93: Prague
IETF93: Prague • •
Similar to a NULL-register
FHR can withdraw the register when it
finds doing so is appropriate (KAT trigger)
Stream-Register Message send by FHR
connection.
Based on hello FHR and RP would learn
To withdraw, set withdraw flag in the same
its peers PORT capabilities.
Once adjacency is formed, RP would
PORT Keep-alive could be used to
register message
PORT Keep-alive could be used to
Stream-Register Message send by FHR
FHR can withdraw the register when it
Similar to a NULL-register
connection.
its peers PORT capabilities.
Once adjacency is formed, RP would
Based on hello FHR and RP would learn
Based on hello FHR and RP would learn
Similar to a NULL-register
Stream-Register Message send by FHR
FHR can withdraw the register when it
finds doing so is appropriate (KAT trigger)
finds doing so is appropriate (KAT trigger)
To withdraw, set withdraw flag in the same
PORT Keep-alive could be used to
register message
connection.
register message
To withdraw, set withdraw flag in the same
its peers PORT capabilities.
Once adjacency is formed, RP would
Reliable PIM Registers
Reliable PIM Registers
Reliable PIM Registers
Clarifications
Clarifications
Clarifications
Robert Kebler (
Robert Kebler (
Robert Kebler (
PIM Registers – How it is today
PIM Registers – How it is today
PIM Registers – How it is today
Hard-State Register Messages
Hard-State Register Messages
Hard-State Register Messages
When a First-Hop-Router (FHR) gets native multicast traffic, this
aliveness of the source
Each individual S, G is “ack’ed” with Register Stop
Subsequent to this, NULL-Registers are used to maintain the
traffic would be tunneled as PIM control packets to RP. These are
PIM registers serve two purposes
PIM registers.
Subsequent to this, NULL-Registers are used to maintain the
Each individual S, G is “ack’ed” with Register Stop
aliveness of the source
When a First-Hop-Router (FHR) gets native multicast traffic, this
traffic would be tunneled as PIM control packets to RP. These are
PIM registers serve two purposes
aliveness of the source
PIM registers.
Each individual S, G is “ack’ed” with Register Stop
PIM registers serve two purposes
Subsequent to this, NULL-Registers are used to maintain the
traffic would be tunneled as PIM control packets to RP. These are
PIM registers.
When a First-Hop-Router (FHR) gets native multicast traffic, this
FHR would discover nearest RP by means of sending targeted
Redistribution of source information
hellos to anycast address.
Reliable full mesh connection among the anycast RP-Set.
FHR would discover nearest RP by means of sending targeted
hellos to anycast address.
Reliable full mesh connection among the anycast RP-Set.
Redistribution of source information
Reliable full mesh connection among the anycast RP-Set.
FHR would discover nearest RP by means of sending targeted
hellos to anycast address.
Redistribution of source information
FHR router upon learning an RP (could be anycast-RP)
This draft extends that to supported pim neighbors over
As per present spec, PIM hellos are link-level
multiple hops reached via its known unicast address
address would transmit targeted hellos
RP could respond to those targeted hellos
capability and could start with reliable-registers
From these hellos RP and FHR would learn the port
RP could respond to those targeted hellos
From these hellos RP and FHR would learn the port
address would transmit targeted hellos
FHR router upon learning an RP (could be anycast-RP)
This draft extends that to supported pim neighbors over
multiple hops reached via its known unicast address
capability and could start with reliable-registers
capability and could start with reliable-registers
This draft extends that to supported pim neighbors over
As per present spec, PIM hellos are link-level
multiple hops reached via its known unicast address
FHR router upon learning an RP (could be anycast-RP)
From these hellos RP and FHR would learn the port
RP could respond to those targeted hellos
As per present spec, PIM hellos are link-level
address would transmit targeted hellos
expected to resort to Packet-Register’s (RFC
problems in Null-Register messages
PIM Null-Register
defaults to 60+5s).
In the FHR, if Register-Stop times-out, its
problems in Null-Register messages
problems in Null-Register messages
expected to resort to Packet-Register’s (RFC
PIM Null-Register
In the FHR, if Register-Stop times-out, its
expected to resort to Packet-Register’s (RFC
defaults to 60+5s).
PIM Null-Register
defaults to 60+5s).
In the FHR, if Register-Stop times-out, its
V 1.1
V 1.1
V 1.1
neighbor properties/capabilities.
New TLV would be added for targeted
Hellos will have TLV’s as specified by
addresses) in its secondary address TLV’s.
would use its unique address and would
RP when responding to targeted hello
add its other address (including anycast
neighbor properties/capabilities.
addresses) in its secondary address TLV’s.
New TLV would be added for targeted
Hellos will have TLV’s as specified by
add its other address (including anycast
addresses) in its secondary address TLV’s.
would use its unique address and would
RP when responding to targeted hello
add its other address (including anycast
would use its unique address and would
New TLV would be added for targeted
RP when responding to targeted hello
Hellos will have TLV’s as specified by
neighbor properties/capabilities. – – – – – – – – – – – – – – –
Management Considerations
Management Considerations
Management Considerations – – – – – – – – – – – – – – – – – –
Register-stops prevent FHR from sending data Registers
It helps in avoiding initial packet loss.
It helps FHR to inform that it is getting traffic for a given (source, group).
Register-stops prevent FHR from sending data Registers
It helps in avoiding initial packet loss.
Register-stops prevent FHR from sending data Registers
It helps in avoiding initial packet loss.
It helps FHR to inform that it is getting traffic for a given (source, group).
It helps FHR to inform that it is getting traffic for a given (source, group).
to all the other any-cast peers.
RP’s would transmit stream-register messages received from FHR
When a new anycast-RP connection is setup, an RP would send to
When a new anycast-RP connection is setup, an RP would send to
RP’s would transmit stream-register messages received from FHR
to all the other any-cast peers.
to all the other any-cast peers.
When a new anycast-RP connection is setup, an RP would send to
RP’s would transmit stream-register messages received from FHR
This could happen even if one RS-message gets
Packet format does not allow state refresh for multiple
Is soft-state based
dropped.
flows in the same message
This could happen even if one RS-message gets
flows in the same message
dropped.
flows in the same message
This could happen even if one RS-message gets
Is soft-state based
Is soft-state based
dropped.
Packet format does not allow state refresh for multiple
Packet format does not allow state refresh for multiple
Feature support needed only on RP and FHR
Incremental deployment is possible
Only configuration needed is an
enable/disable knob for reliable register (No
need configure peers)
need configure peers)
Feature support needed only on RP and FHR
Incremental deployment is possible
Only configuration needed is an
enable/disable knob for reliable register (No
need configure peers)
Incremental deployment is possible
Feature support needed only on RP and FHR
enable/disable knob for reliable register (No
Only configuration needed is an
(draft-anish-reliable-pim-register)
(draft-anish-reliable-pim-register)
(draft-anish-reliable-pim-register)
Targeted hellos (cont.)
Targeted hellos (cont.)
Targeted hellos (cont.)
Connection Setup
Connection Setup
Connection Setup 8
PIM WG
PIM WG
Anycast RP 7
Anycast RP 8
PIM WG 9
PIM WG 10 )
Observations
Vikram Nagarajan (
Anish Peter ( 7
Thank You
Opinions
PIM WG
&
PIM WG
PIM WG ) )
Vikram Nagarajan (
Anish Peter (
PIM WG
&
Opinions
Thank You 10 )
July-2015
PIM WG 3
PIM WG 5 6
Observations
PIM WG
PIM-WG, IETF-92 2 9
PIM WG ) 10
PIM WG
Thank You
PIM WG
Opinions 9
PIM WG )
PIM WG 8
Anycast RP 3
&
July-2015 )
PIM-WG, IETF-92 2
PIM WG
Vikram Nagarajan (
Anish Peter ( ) ) 7
PIM WG
PIM WG
Observations 3
PIM WG 2 6
July-2015
PIM WG
PIM-WG, IETF-92
PIM WG 5 5
PIM WG 6
PIM WG
Reliable PIM Registers draft-anish-reliable-pim-register
Stig Venaas,
Toerkess Eckert,
Anish Peter,
Robert Kebler,
Vikram Nagarajan
IETF March-2018
connect to FHR to form the reliable
connect to FHR to form the reliable
connect to FHR to form the reliable
PIM register-stop messages inherit all the
PIM register-stop messages inherit all the
PIM register-stop messages inherit all the
the peers all the stream-registers it had learned from FHR.
the peers all the stream-registers it had learned from FHR.
the peers all the stream-registers it had learned from FHR.
maintain aliveness of session.
maintain aliveness of session.
maintain aliveness of session.
PORT for reliable connection setup
PORT for reliable connection setup
PORT for reliable connection setup

2. Motivation to be added to next rev of draft• • • • •
IETF93: Prague • • •
IETF93: Prague
IETF93: Prague • •
IETF93: Prague • • •
IETF93: Prague • • • • • • • • •
IETF93: Prague •
IETF93: Prague
IETF93: Prague •
Once adjacency is formed, RP would
its peers PORT capabilities.
To withdraw, set withdraw flag in the same
connection.
register message
Based on hello FHR and RP would learn
finds doing so is appropriate (KAT trigger)
Similar to a NULL-register
Stream-Register Message send by FHR
FHR can withdraw the register when it
PORT Keep-alive could be used to
Reliable PIM Registers
Clarifications
Robert Kebler (
PIM Registers – How it is today
Hard-State Register Messages
aliveness of the source
When a First-Hop-Router (FHR) gets native multicast traffic, this
PIM registers.
Each individual S, G is “ack’ed” with Register Stop
traffic would be tunneled as PIM control packets to RP. These are
Subsequent to this, NULL-Registers are used to maintain the
PIM registers serve two purposes
FHR and RP
Use TCP/SCTP
Reliable-Registers would support a reliable transport between
Create a “targeted” adjacency between FHR and RP
FHR sends message to RP to add/remove active sources
Redistribution of source information
Reliable full mesh connection among the anycast RP-Set.
FHR would discover nearest RP by means of sending targeted
hellos to anycast address.
In the FHR, if Register-Stop times-out, its
defaults to 60+5s).
expected to resort to Packet-Register’s (RFC
problems in Null-Register messages
PIM Null-Register
V 1.1
RP when responding to targeted hello
add its other address (including anycast
addresses) in its secondary address TLV’s.
New TLV would be added for targeted
Hellos will have TLV’s as specified by
neighbor properties/capabilities.
would use its unique address and would – – – – – – – – – – –
Management Considerations – – – – – –
It helps in avoiding initial packet loss.
Register-stops prevent FHR from sending data Registers
It helps FHR to inform that it is getting traffic for a given (source, group).
Can use Anycast-RP address to find closest RP
New messages created to notify of new active source
Sends PIM Hellos with normal Hello Options to advertise capabilities
These routers form adjacency.
Reliability and Flow control
Some of the same encoding as RFC 6559 (PIM PORT)
RP’s would transmit stream-register messages received from FHR
When a new anycast-RP connection is setup, an RP would send to
to all the other any-cast peers.
flows in the same message
This could happen even if one RS-message gets
dropped.
Packet format does not allow state refresh for multiple
Is soft-state based
Feature support needed only on RP and FHR
need configure peers)
enable/disable knob for reliable register (No
Incremental deployment is possible
Only configuration needed is an
(draft-anish-reliable-pim-register)
Targeted hellos (cont.)
Reliable Registers
Connection Setup
Opinions
&
Thank You
PIM WG
Anish Peter ( 9
PIM WG 10 7
Observations
PIM WG )
PIM WG
PIM WG 6 3 4
PIM WG
PIM WG 2
PIM WG 8
Anycast RP )
PIM-WG, IETF-92
Vikram Nagarajan (
July-2015 )
Motivation to be added to next rev of draft
draft-acg-mboned-deprecate-interdomain-asm
Deprecate ASM/PIM-SM interdomain -> Interdomain MSDP too
MSDP intradomain for MSDP mesh group unaffected
MSDP mesh-group compared to PIM RP mesh group (RFC4610)
MSDP only IPv4, RFC4610 IPv4/IPv6, but MSDP has better performance, operational features
Reliable transport (TCP): Works reliable especially under bursts (large #state)
Even without anycast-RP: Big video server (large #(S,G)) to RP: Datagram PIM Hello issues
Recommendation: make FHR be RP, use MSDP to overcome PIM Register issues
MIB, YANG model, cache (which RP sent which (S,G)), limits (#state), filter (AC) – better Mgmt
Want to have TCP (== PORT) based RFC4610 variant
also improve (see example above) FHR-DR<->RP reliability/performance
Finally deprecate MSDP (without loosing reliability, performance, manageability)
Define MSDP anycast equivalent YANG model for reliable PIM register
connect to FHR to form the reliable
PIM register-stop messages inherit all the
the peers all the stream-registers it had learned from FHR.
maintain aliveness of session.
PORT for reliable connection setup

3. PIM Registers – How it is today• • • • •
IETF93: Prague • • •
IETF93: Prague
IETF93: Prague • •
IETF93: Prague • • •
IETF93: Prague • • • • • • • • •
IETF93: Prague •
IETF93: Prague
IETF93: Prague •
Once adjacency is formed, RP would
its peers PORT capabilities.
To withdraw, set withdraw flag in the same
connection.
register message
Based on hello FHR and RP would learn
finds doing so is appropriate (KAT trigger)
Similar to a NULL-register
Stream-Register Message send by FHR
FHR can withdraw the register when it
PORT Keep-alive could be used to
Reliable PIM Registers
Clarifications
Robert Kebler (
PIM Registers – How it is today
Hard-State Register Messages
aliveness of the source
When a First-Hop-Router (FHR) gets native multicast traffic, this
PIM registers.
Each individual S, G is “ack’ed” with Register Stop
traffic would be tunneled as PIM control packets to RP. These are
Subsequent to this, NULL-Registers are used to maintain the
PIM registers serve two purposes
FHR and RP
Use TCP/SCTP
Reliable-Registers would support a reliable transport between
Create a “targeted” adjacency between FHR and RP
FHR sends message to RP to add/remove active sources
Redistribution of source information
Reliable full mesh connection among the anycast RP-Set.
FHR would discover nearest RP by means of sending targeted
hellos to anycast address.
In the FHR, if Register-Stop times-out, its
defaults to 60+5s).
expected to resort to Packet-Register’s (RFC
problems in Null-Register messages
PIM Null-Register
V 1.1
RP when responding to targeted hello
add its other address (including anycast
addresses) in its secondary address TLV’s.
New TLV would be added for targeted
Hellos will have TLV’s as specified by
neighbor properties/capabilities.
would use its unique address and would – – – – – – – – – – –
Management Considerations – – – – – –
It helps in avoiding initial packet loss.
Register-stops prevent FHR from sending data Registers
It helps FHR to inform that it is getting traffic for a given (source, group).
Can use Anycast-RP address to find closest RP
New messages created to notify of new active source
Sends PIM Hellos with normal Hello Options to advertise capabilities
These routers form adjacency.
Reliability and Flow control
Some of the same encoding as RFC 6559 (PIM PORT)
RP’s would transmit stream-register messages received from FHR
When a new anycast-RP connection is setup, an RP would send to
to all the other any-cast peers.
flows in the same message
This could happen even if one RS-message gets
dropped.
Packet format does not allow state refresh for multiple
Is soft-state based
Feature support needed only on RP and FHR
need configure peers)
enable/disable knob for reliable register (No
Incremental deployment is possible
Only configuration needed is an
(draft-anish-reliable-pim-register)
Targeted hellos (cont.)
Reliable Registers
Connection Setup
Opinions
&
Thank You
PIM WG
Anish Peter ( 9
PIM WG 10 7
Observations
PIM WG )
PIM WG
PIM WG 6 3 4
PIM WG
PIM WG 2
PIM WG 8
Anycast RP )
PIM-WG, IETF-92
Vikram Nagarajan (
July-2015 )
PIM Registers – How it is today
First-Hop-Router (FHR-DR) tunnels via PIM (unicast) “Register” message/encap sources (S,G) packets to.
PIM registers serve two purposes
It helps FHR to inform that it is getting traffic for a given (source, group).
It helps in avoiding initial packet loss.
Each individual S, G is “ack’ed” with Register Stop
Register-stops prevent FHR from sending data Registers
Subsequent to this, NULL-Registers are used to maintain the aliveness of the source
Many Multicast applications are tolerant to initial packet loss.
Many intradomain Multicast applications are not ssm capable.
Forcing networks to run on asm mode.
connect to FHR to form the reliable
PIM register-stop messages inherit all the
the peers all the stream-registers it had learned from FHR.
maintain aliveness of session.
PORT for reliable connection setup

4. Observations PIM Null-Register
Is soft-state based
Packet format does not allow state refresh for multiple flows in the same message
PIM register-stop messages inherit all the problems in Null-Register messages
In the FHR, if Register-Stop times-out, its expected to resort to Packet-Register’s (RFC defaults to 60+5s).
This could happen even if one RS-message gets dropped.

5. Reliable Registers
Reliable-Registers would support a reliable transport between FHR and RP
Create a “targeted” adjacency between FHR and RP
These routers form adjacency.
Sends PIM Hellos with normal Hello Options to advertise capabilities
Can use Anycast-RP address to find closest RP
Use TCP/SCTP
Some of the same encoding as RFC 6559 (PIM PORT)
Reliability and Flow control
New messages created to notify of new active source
FHR sends message to RP to add/remove active sources

6. Targeted Hellos As per present spec, PIM hellos are link-level
This draft extends that to supported pim neighbors over multiple hops reached via its known unicast address
FHR router upon learning an RP (could be anycast-RP) address would transmit targeted hellos
RP could respond to those targeted hellos
From these hellos RP and FHR would learn the port capability and could start with reliable-registers
RP when responding to targeted hello would use its unique address and would add its other address (including anycast addresses) in its secondary address TLV’s.
New TLV would be added for targeted neighbor properties/capabilities.
Hellos will have TLV’s as specified by PORT for reliable connection setup

7. Connection Setup
Based on hello FHR and RP would learn its peers PORT capabilities.
Once adjacency is formed, RP would connect to FHR to form the reliable connection.
PORT Keep-alive could be used to maintain aliveness of session.

8. Hard-State Register Messages
Stream-Register Message send by FHR
Similar to a NULL-register
FHR can withdraw the register when it finds doing so is appropriate (KAT trigger)
To withdraw, set withdraw flag in the same register message

9. Anycast RP
FHR would discover nearest RP by means of sending targeted hellos to anycast address.
Reliable full mesh connection among the anycast RP-Set.
Redistribution of source information
RP’s would transmit stream-register messages received from FHR to all the other any-cast peers.
When a new anycast-RP connection is setup, an RP would send to the peers all the stream-registers it had learned from FHR.

10. Management Considerations
Only mandatory configuration needed is an enable/disable knob for reliable register/packet registers (No need configure peers)
Incremental deployment is possible
Feature support needed only on RP and FHR

11. Security Considerations
Can help improve the pim register attack vulnerability
TCP sync attack vulnerability is limited due to targeted hello session
Targeted hellos are introduced, which may in future have an authentication extension for FHR

12. Next steps Please review, discuss on mailing list
Call for working group adoption (IETF102 ?!)
Open work
Policy for register encap of actual data packet (not null register)
What do we want ?
YANG model
Creates ask for manageability features of registers (cache, limit, filter)
Possible extensions
Source control (RP based permit/deny of (S,G) via register msg
Simple oversight for original PIM register message mechanism (next rev)

13. Thank You
Opinions
&
Clarifications

14. Summary: FHR <-> RP
FHR and RPs configured to support this feature (part of port ? TBD)
FHR learns RP as usual (configuration or discovery via BSR)
FHR that is DR exchanges new directed (unicast) PIM Hello (datagram) with RP (FH-DR start)
After RP sees directed PIM Hello, opens TCP Reliable Register (PORT-Register) to FHR-DR
Two routers who are both DR and RP: determine which is TCP initiator
same method as in PORT (RFC6559)
Reset situation via Directed PIM Hello with updated GenID, rebuild TCP connection
Reconfiguration, redundancy failover (route processor), …
Timeout (various error conditions) -> rebuild after directed PIM hello rediscovers neighbor mutually

15. Summary: RP <-> RP (Anycast RP)
Mesh-group-logic: like RFC4610
Full mesh of onfigured RP-neighbors
Remember per (S,G) whether receeived from mesh-group tunnel peer or FHR-DR tunnel peer
Forward only FHR-DR learned (S,G) to mesh-group-peer
For diagnostics (not protocol) good to remember exact neighbor (S,G) was learned from)
Anycast FHR-DR to RP relies on anycast to unicast resolution via directed PIM Hello
Learned/configured peer address can be anycast (from PR).
Directed PIM Hello signals “primary address” PIM option so other side can learn unicast IP address for TCP connection
Backward compatibility – MSDP peers, legacy PIM Register peers
Defined. Not sure if MSDP should still be mentioned, legacy PIM peer support more important for migration. Easier to change RP set to be capable of new mechanisms than all FHR-DR at once)

16. Protocol: New Hello Optional TLV's (IPv4/IPv6)
| Type = H1 (for alloc) | Length = 4 | |F|R| Reserved | Exp |

17. Protocol: Port Register Message TLV (IPv4/IPv6)
| Type = P1 (for alloc) | Message Length | | Reserved | Exp. | |B|N|A| Reserved-1 | | src addr-1 z z grp addr-1 | z 2, 3, z |B|N|A| Reserved-n | | src addr-n z z grp addr-n |

18. Protocol: Port Register Stop Message TLV (IPv4/IPv6)
| Type = P2(for alloc) | Message Length | | Reserved | Exp. | | Reserved-1 | | src addr-1 z z grp addr-1 | z 2, 3, z | Reserved-n | | src addr-n z z grp addr-n |