SCENARIOS ABC

1
A Two-Level Architecture for Internet
Signaling draft-braden-2level-signal-arch-00.txt
Bob Braden, Bob Lindell
2
References

• RFC 1191 co ST-II, ST Control Message
  Protocol
• RFC 2205 RSVP v1 Functional Spec
• RFC 2961 RSVP Refresh Overhead Reduction
  Extensions
• RFC 3124 The Congestion Manager
• RFC 2998 A Framework for Intserv Operation
  over Diffserv
• RFC 2747 RSVP Cryptographic Authentication

3
Background and Motivation

• RSVP v1 has been expanded to define a suite of
  Internet signaling protocols
• QoS setup across diff-serv clouds
• Setting up MPLS paths with QoS
• VPN provisioning
• Configuring optical networks
• QoS setup for PacketCable
• Active interest filtering for distributed
  simulation
• Build Internet Signaling Protocol Suite (ISPS)
  with improved modularity
• common lower level transport-level functions
  CSTP
• set of upper-level signaling functions that are
  signaling app specific ALSP

4
Terminology

• Path-directed signaling install, modify and
  remove state in routers and other entities along
  the path of some particular data flow operates
  in the nodes along a data path between signaling
  end-points p-src -- p-sink
• p-src and p-sink may be end systems or
  intermediate nodes (e.g. tunnel endpoints)
• Upstream and downstream relative to the data
  flow
• Data flows downstream
• Signaling may occur in one or both directions
• CSTP neighbors and CSTP direct neighbors
• signaling messages are sent hop-by-hop (h-src --
  h-snk)

5
Terminology

• Signaling Application Protocol Unit (SAPU)
  basic transmission unit for signaling
• is used to set/modify/delete state in the h-sink
  node
• Trigger/Refresh messages
• Trigger installs/modifies/deletes signaled state
• Refresh refreshes existing state (prevents it
  from timing out)

6
Common Signaling Transport Protocol basic features

• CSTP does not have end-to-end semantics
• CSTP handles only the dynamics of reliably
  transmitting signaling state between neighbors
  h-src -- h-sink and of refreshing this as soft
  state (neighbor list is part of the soft state)
• CSTP can perform complex scheduling of signaling
  message transmission (might limit the rate of
  signaling)
• CSTP might be a candidate for the Congestion
  Manager RFC 3124
• CSTP transports SAPUs in down/up stream
  signaling messages

7
Common Signaling Transport Protocol requirements

• Support simplex or full-duplex signaling
• Support receiver- or sender-initiated signaling
• e.g. RSVP receiver oriented operation and
  reservation styles do not appear in CSTP, only in
  the RSVP specific ALSP module
• Support for Path-directed signaling
• some ALSP may not make use of this capability
• Support different granularity of data flow
  (micro-flows, highly-aggregated flows)
• RSVP v1 support (CSTP, ALSP) design RSVP v2
• Reliable delivery of signaling messages
• The reliable delivery algorithm must consider
  fragmentation (should be able to retransmit
  individual fragments of large SAPU)
• Ordered delivery of SAPUs
• CSTP has mechanisms to ignore out-of-order
  trigger messages

8
Common Signaling Transport Protocol requirements

• Soft state support (remove orphan states)
• A particular ALSP may choose to not use it
• Fragmentation, re-assembly and bundling of SAPUs
• CSTP must be able to fragment/reassemble SAPUs
  that exceed MTU
• Bundling carrying multiple small SAPUs in a
  single IP datagram
• Full Internet layer support (IPv4, IPv6,
  unicast/multicast, IPSec)
• Partial deployment
• Signaling protocols must be able to operate
  through CSTP-incapable nodes
• Congestion control
• all Internet traffic should be responsive to
  congestion
• TCP friendly congestion control can be applicable
  to CSTP
• Hop-by-hop integrity
• e.g. RSVP Cryptographic Authentication, RFC 2747

9
CSTP Signaling Messages
XDown/Up

• xSig(NEW, h-src, SAPUid, )
• xSig(MOD, )
• xSig(TEAR,)
• xSig(REFRESH,)
• xSig(ACK,)
• xSig(NACK,)
• xSig(EVENT,)
• xSig(CHALLENGE,)
• xSig(RESPONSE,)