Switching and routing in Future Network Workshop on

advertisement
Joint ITU-T SG 13 and ISO/JTC1/SC 6
Workshop on
“Future Networks Standardization”
(Geneva, Switzerland, 11 June 2012)
Switching and routing
in Future Network
John Grant
Nine Tiles
j@ninetiles.com
www.iec62379.org/FN-standardisation.html
Geneva, Switzerland, 11 June 2012
Network layer
the one part of the stack that's universal
users
applications
transport protocols
routing
encapsulation
physical layers
Geneva, Switzerland, 11 June 2012
2
like ISO 668, 1161, ...
Geneva, Switzerland, 11 June 2012
Two kinds of data
static
dynamic
content
files, 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
4
Two kinds of service
(not 1, not 4)
Synchronous
appropriate for dynamic data
one-to-many
packets sent at regular intervals
QoS guarantees (if supported by lower layers)
Asynchronous
appropriate for static data
one-to-one or many-to-one
best-effort service
Geneva, Switzerland, 11 June 2012
Connection-oriented paradigm
Required for synchronous
needed for QoS etc negotiation
Useful for both kinds
offers facilities such as per-call billing
Fits many current protocols
TCP
SIP
“sockets” API
Geneva, Switzerland, 11 June 2012
6
Connection-oriented paradigm
Provides separation between:
global addressing (in set-up messages)
local routing (in packets)
Enables new routing technologies
no “world launch day” needed
Connection-oriented ≠ TDM
though FN supports use of TDM and
WDM circuits
Geneva, Switzerland, 11 June 2012
7
Connection-oriented paradigm
“Link” between network elements
may be:
point-to-point connection
shared media (e.g. WiFi, LTE)
legacy network, including connectionless
Provides migration path
on legacy network, only edge / gateway
devices need to implement FN
Geneva, Switzerland, 11 June 2012
8
Switch structure
controller (computer)
routing table
inputs
logic
Geneva, Switzerland, 11 June 2012
control
packets
etc
buffer
memory
scheduling
logic
outputs
Addressing
Access to a service by name in IP
use DNS, SIP, etc, to find IP address
IP address is then used for packet routing
switches use ARP to find lower-layer address
problems with mobility etc
documented in TR29181
Geneva, Switzerland, 11 June 2012
10
Addressing
Access to a service by name in FN
put service name in signalling message
reply includes a “handle” for the route
handle format depends on the link
technology for the first hop
each network element only needs to
know the local part of the route
rerouting, handover, etc are transparent
Geneva, Switzerland, 11 June 2012
11
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
12
Fast set-up for asynchronous
FN has an equivalent for connectionoriented
connection to server is many-to-one
return route set up by switching fabric
does not involve controller software
described in 8.2 of 29181-3
Geneva, Switzerland, 11 June 2012
13
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 interface
may also be a service or some content
also includes a globally-unique “call
identifier”
Geneva, Switzerland, 11 June 2012
14
Finding a route
Multiple addressing schemes
must support legacy schemes, e.g.
IPv4, IPv6
must also support URLs etc
must allow new schemes to be added
decoupling 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
15
Finding a route
Controller in each switch decides the
next hop
topology discovery depends on the
address scheme
in sub-networks, may simply flood the
request to all neighbours
loops easy to detect
not scalable to large networks
Geneva, Switzerland, 11 June 2012
16
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
17
Control / signalling protocol
Tag-length-value format
like Q.931, Q.2931; unlike SIP
suitable for small embedded processors
no character string interpretation required
appropriate 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
18
Next steps
Find a name without “future” in it
soon (2015?) it’ll be in the present
Standardize signalling messages
including route-finding protocols
Standardize new lower layer(s)
QoS for synchronous flows
low overhead per packet
all capacity not used by synchronous
flows available for asynchronous
Geneva, Switzerland, 11 June 2012
19
Download