1 / 19

Switching and routing in Future Network

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. Network layer. users. applications.

mistym
Télécharger la présentation

Switching and routing in Future Network

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Joint ITU-T SG 13 and ISO/JTC1/SC 6 Workshop on “Future Networks Standardization”(Geneva, Switzerland, 11 June 2012) Switching and routingin Future Network John Grant Nine Tiles j@ninetiles.com www.iec62379.org/FN-standardisation.html

  2. Network layer users applications transport protocols • the one part of the stack that's universal routing encapsulation physical layers

  3. like ISO 668, 1161, ...

  4. Two kinds of data

  5. 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

  6. 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

  7. 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

  8. 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

  9. Switch structure logic logic logic logic controller (computer) control packets etc routing table scheduling buffer memory inputs outputs

  10. 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

  11. 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

  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 12

  13. Fast set-up for asynchronous • FN has an equivalent for connection-oriented • 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

  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 interface • may also be a service or some content • also includes a globally-unique “call identifier” Geneva, Switzerland, 11 June 2012 14

  15. 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

  16. 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

  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 17

  18. 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

  19. 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

More Related