Geneva, Switzerland, 11 June 2012

Switching and routingin Future Network

John GrantNine Tiles

j@ninetiles.comwww.iec62379.org/FN-standardisation.html

Joint ITU-T SG 13 and ISO/JTC1/SC 6 Workshop on

“Future Networks Standardization”

(Geneva, Switzerland, 11 June 2012)

Geneva, Switzerland, 11 June 2012 2

the one part of the stack that's universal

Network layer

routing

encapsulation

physical layers

applications

transport protocols

users

Geneva, Switzerland, 11 June 2012

like ISO 668, 1161, ...

Geneva, Switzerland, 11 June 2012 4

Two kinds of data

static dynamic

contentfiles, web pages, etc

audio, video, voice

context IT AV; real world

traffic bursty regular

service best effort needs QoS

IP designed for?

yes no

Geneva, Switzerland, 11 June 2012

Two kinds of service

Synchronousappropriate for dynamic dataone-to-manypackets sent at regular intervalsQoS guarantees (if supported by lower layers)

Asynchronousappropriate for static dataone-to-one or many-to-onebest-effort service

(not 1, not 4)

Geneva, Switzerland, 11 June 2012 6

Connection-oriented paradigm

Required for synchronousneeded for QoS etc negotiation

Useful for both kindsoffers facilities such as per-call billing

Fits many current protocolsTCPSIP“sockets” API

Geneva, Switzerland, 11 June 2012 7

Connection-oriented paradigm

Provides separation between:global addressing (in set-up messages)local routing (in packets)

Enables new routing technologiesno “world launch day” needed

Connection-oriented ≠ TDMthough FN supports use of TDM and WDM circuits

Geneva, Switzerland, 11 June 2012 8

Connection-oriented paradigm

“Link” between network elements may be:

point-to-point connectionshared media (e.g. WiFi, LTE)legacy network, including connectionless

Provides migration pathon legacy network, only edge / gateway devices need to implement FN

Geneva, Switzerland, 11 June 2012

Switch structure

controller (computer)

routing table

buffermemory

inputs outputs

control packets etc

logiclogiclogiclogic

scheduling

Geneva, Switzerland, 11 June 2012 10

Addressing

Access to a service by name in IPuse DNS, SIP, etc, to find IP addressIP address is then used for packet routing

switches use ARP to find lower-layer address

problems with mobility etcdocumented in TR29181

Geneva, Switzerland, 11 June 2012 11

Addressing

Access to a service by name in FNput service name in signalling messagereply includes a “handle” for the routehandle format depends on the link technology for the first hopeach network element only needs to know the local part of the routererouting, handover, etc are transparent

Geneva, Switzerland, 11 June 2012 12

Fast set-up for asynchronous

HTTP typically uses many short TCP sessions

after the first, the addresses are already in the routing table

for popular web sites, destination is there even for the first

return route can be cached as the SYN packet is forwarded

Geneva, Switzerland, 11 June 2012 13

Fast set-up for asynchronous

FN has an equivalent for connection-oriented

connection to server is many-to-onereturn route set up by switching fabric

does not involve controller software

described in 8.2 of 29181-3

Geneva, Switzerland, 11 June 2012 14

Finding a route

Application sends request to local controller on signalling channel

includes address (or other identification) of target

target is the equipment, not its interfacemay also be a service or some content

also includes a globally-unique “call identifier”

Geneva, Switzerland, 11 June 2012 15

Finding a route

Multiple addressing schemesmust support legacy schemes, e.g. IPv4, IPv6must also support URLs etc

must allow new schemes to be addeddecoupling global addressing from local routing means no change is needed to lower-layer switching logic

unlike the change from IPv4 to IPv6

Geneva, Switzerland, 11 June 2012 16

Finding a route

Controller in each switch decides the next hop

topology discovery depends on the address schemein sub-networks, may simply flood the request to all neighbours

loops easy to detectnot scalable to large networks

Geneva, Switzerland, 11 June 2012 17

Finding a route

Controller checks required capacity is available

provided the switching technology supports it

Labelling of packets depends on link technology

route may pass over several different technologies

Geneva, Switzerland, 11 June 2012 18

Control / signalling protocol

Tag-length-value formatlike Q.931, Q.2931; unlike SIPsuitable for small embedded processors

no character string interpretation requiredappropriate for Internet of Things

easy to skip unrecognized / uninteresting items

some for network, some for remote application

Could be based on IEC 62379-5-2

Geneva, Switzerland, 11 June 2012 19

Next steps

Find a name without “future” in itsoon (2015?) it’ll be in the present

Standardize signalling messagesincluding route-finding protocols

Standardize new lower layer(s)QoS for synchronous flowslow overhead per packetall capacity not used by synchronous flows available for asynchronous