80 likes | 110 Views
Multihoming: the SCTP perspective. Multihoming IPv6 Working Group multi6 Lode.Coene@Siemen s . com. SCTP: Stream Control Transmission Protocol. Described in RFC 2960 and 3309 Multihomed host: endpoint with more than one IP address allocated to it.
E N D
Multihoming: the SCTP perspective Multihoming IPv6 Working Group multi6 Lode.Coene@Siemens.com
SCTP: Stream Control Transmission Protocol • Described in RFC 2960 and 3309 • Multihomed host: endpoint with more than one IP address allocated to it. • Each IP address represents a path through the network towards that endpoint and has separate congestion control variables • SCTP does NOT know if the paths are completely, partly or not distinct at all from each other. • Ideally: we would like all paths to be completely distinct • Practice: we simply don’t know... • Heartbeats for every path: keeps paths variables up-to-date and checks if the path is alive. Title presentation
SCTP multihoming Title presentation
SCTP: Stream Control Transmission Protocol • Multihoming did open some new horizons for us: • Add/remove IP address: in draft version <draft-ietf-tsvwg-addip-sctp-07.txt> • Based on add/remove IP, mobility support by the endpoint/host <draft-riegel-tuexen-mobile-sctp-02.txt>.. And some other drafts(got already out of hand I think...) • Loadsharing accross the different paths of a multihomed association: still a research issue, but it is certain that the endpoint has a better view of loadsharing than any node within the path ... • Proves that things that are done at the endpoint are really simplere and more powerfull than doing it in the network... OK, alllright ..The end-to-end principle rules...happy now... • In conjuction with partial-relialebility SCTP(PR-SCTP)... better quality video?!?!.. <draft-ietf-tsvwg-prsctp-00.txt> Title presentation
SCTP: Stream Control Transmission Protocol • Some multihoming issues are documented in RFC 3257: • Some multihoming issues are documented in <draft-coene-sctp-multihome-04.txt> • Host needs routing table: no big deal for host with a limited number of associations/connections to different remote peers • Needs a big table in case of lots of associations/connections to lots of remote peers, but it is just throwing memory at the problem on the host, so this is no big deal either • How to fill in the routing table: implementation dependant: preconfigured,.. Caching when sending or receiving the INIT(=start of SCTP association)... Title presentation
SCTP: Stream Control Transmission Protocol • Some multihoming and NAT interworking issues are documented in <draft-coene-sctp-multihome-04.txt> • Allright, I know this ain’t a NAT WG • But we put it in to be sure • We know in any case, trying to resolve that for the general case would require communication and coordination between the different NAT boxes anyway. And it looks like a very hard problem in the n*m range, so lets leave it there... • Observation: If multiple, distinct paths towards a remote destination had been in IP from the start on, NAT boxes wouldn’t have had a chance in Hell of being introduced or used in the network. (I should know, because in the network I do(SS7) I have yet to see the first NAT box being used) Title presentation
Conclusion • View from the transport plane: • SCTP :we are getting along with the present solutions • TCP: see Christians draft <draft-huitema-multi6-experiment-00.txt> • It works... Title presentation