DOCSLIB.ORG

Thread Border Router Best Practices

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Thread Border Router Best Practices March 2018 This Thread Technical white paper is provided for reference purposes only. The full technical specification is available publicly. To join gain access, please follow this link: https://www.threadgroup.org/ThreadSpec. If there are questions or comments on these technical papers, please send them to [email protected]. This document and the information contained herein is provided on an “AS IS” basis and THE THREAD GROUP DISCLAIMS ALL WARRANTIES EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO (A) ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OF THIRD PARTIES (INCLUDING WITHOUT LIMITATION ANY INTELLECTUAL PROPERTY RIGHTS INCLUDING PATENT, COPYRIGHT OR TRADEMARK RIGHTS) OR (B) ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE OR NONINFRINGEMENT. IN NO EVENT WILL THE THREAD GROUP BE LIABLE FOR ANY LOSS OF PROFITS, LOSS OF BUSINESS, LOSS OF USE OF DATA, INTERRUPTION OF BUSINESS, OR FOR ANY OTHER DIRECT, INDIRECT, SPECIAL OR EXEMPLARY, INCIDENTAL, PUNITIVE OR CONSEQUENTIAL DAMAGES OF ANY KIND, IN CONTRACT OR IN TORT, IN CONNECTION WITH THIS DOCUMENT OR THE INFORMATION CONTAINED HEREIN, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH LOSS OR DAMAGE. Copyright © 2015 Thread Group, Inc. All rights reserved. Table of Contents Terminology 4 Introduction 5 Use Cases and Requirements 6 Goals and Non-Goals of This Document 6 Requirements for In-Scope Features 6 Proposed Solution Summary 8 Protocols Summary 8 Assumed Customer Environment Summary 9 Device and Service Discovery Summary 9 Border Router Device Categories 9 Connectivity Summary 10 Global Connectivity 10 Site Connectivity 12 Security and Firewalling 12 Protocol Applicability Summary 13 Best Practices 14 Connectivity to IPv4 Destinations 14 Border Router as IPv4 LAN Host and DHCPv4 Client 14 NAT64: Thread Client Connectivity to IPv4 Servers 14 DNS64: Thread Client Locating IPv4 Servers 15 Thread Servers and IPv4 Clients 15 Connectivity to IPv6 Destinations 17 Routing Differences for IPv6 Connectivity Compared to IPv4 17 IPv6 Routing and Forwarding 19 IPv6 Prefix Allocation and Delegation 20 Prefix Delegation with Dynamic Host Configuration Protocol (DHCPv6-PD) 20 Prefix Allocation with Home Network Control Protocol (HNCP) 20 Mixed HNCP and DHCPv6 Prefix Delegation 21 2 Routing Distinct IPv6 Subnets 21 Router Advertisements on Non-Thread Links 22 Dynamic Routing with Babel 22 IPv6 Thread Servers and Non-Thread Clients 22 Security for Thread Management Framework Communications 22 IP Multicast 23 Appendix: Application Layer Specific Services 24 Service Discovery and Application Layer Proxies 24 Virtual Private Networks (VPNs) 25 IPv4 / IPv6 service and device deployment 25 Public Internet attack surface 25 Network Address Translation (NAT) and service provider traversal and keep-alive and asynchronous Internet ingress traffic 25 API and interaction pervasiveness and consistency 26 Path redundancy 26 VPN Benefits to Cloud Service Providers 26 TCP connection scaling 26 Routing and Addressing 27 References 30 3 Terminology TERM DEFINITION CPE Customer Premises Equipment (Typically an ISP-provided Modem or Modem + Router). DNS64 A technology and technique described in [RFC6147] whereby IPv6- only clients are provided, when used in conjunction with NAT64, with synthesized DNS AAAA records by translating actual IPv4-only A records. ISP Internet Service Provider IPv6 Transition Services needed to migrate the Internet from IPv4 to IPv6. IPv6 Mechanisms for interconnecting IPv6 networks via IPv4 networks. Translation and Tunneling NAT Network Address Translation NAT64 An IPv6 Transition technology that enables communications between IPv6-only nodes and IPv4-only nodes by using a form of network address translation (NAT) among a single IPv4 address and IPv4- embedded IPv6 addresses. See [RFC6146]. ND Neighbor Discovery 4 Introduction In a Thread network, the Border Router is an important piece of infrastructure. It facilitates communication of Internet Protocol (IP) packets into and out of the Thread network. In most Thread networks the Border Router will be responsible for providing full Internet communication to Thread devices. It is highly desirable that Thread device vendors can create products that can be easily commissioned onto a Thread network, after which those devices can rely on standard networking functions for IP communications – be it with other networks in the home, or servers hosted on the Internet. All of this should be done in a way that is broadly interoperable and common for Thread devices and Border Routers from various vendors. Thread Group aims for a functionality and end-user experience similar to that of Wi-Fi access points and home routers, whereby Wi-Fi devices can be relied upon to automatically obtain their IP networking configuration and are automatically provided a route to the wider Internet, as well as IP connectivity to other types of networks in the home such as Ethernet. End-to-end IPv6 routability is not yet available in every home (although Ipv6 availability has grown significantly in the last years and continues to grow). This white paper will go into some detail on the selection and implementation of suitable IPv6 Translation and Tunneling technologies, such as NAT64 and DNS64, to achieve an optimal user experience even when an ISP offers IPv4 only in the user’s home network. This document is not a replacement for any part of the Thread specifications; it is designed to act as a guide suggesting best practices and optimal technology selection for vendors that are looking to create a (generic) Thread Border Router. Any requirements language (capitalized “MUST”, “SHOULD”, etc.) only holds for a device that claims full compliance to these best practices. 5 Use Cases and Requirements Goals and Non-Goals of This Document The goals of this white paper include: ● Detailing how to design a generic Thread Border Router that facilitates ○ Site connectivity: Thread Routers and End-devices achieve end-to-end IP communication with other networks in the home (Wi-Fi, Ethernet) ○ Global connectivity: Thread Routers and End-devices achieve end-to-end IP communication with other networks outside the home (WAN, via home Internet connections such as DSL, DOCSIS, GPON or 3G/4G/5G cellular) ● Referencing the Thread specification and RFCs defined by the IETF, whenever possible to provide guidance for implementers ● Focusing on the most common residential networking scenarios and providing solutions for those ● Listing requirements and services to enable a generic Thread Border Router to support multiple vendor ecosystems and multiple IP-based application-layer technologies. Non-goals of this document include: ● Defining which application-layer technologies a Thread Border Router should implement ● Proposing changes to (the behavior of) any non-Thread equipment such as upstream CPE routers, Wi-Fi access points, or cable modems. ● Provide details for gateway functions to translate communications to or from non- IP networks. Requirements for In-Scope Features The following requirements were used as the basis to draft this best-practices white paper. The term “recommendations” below refers to the recommended best practices as listed in this paper. 1. Standards Based 1.1. Recommendations SHOULD be based on existing standards 1.2. Recommendations SHOULD reference Thread specification and IETF RFCs when possible 1.3. Recommendations SHOULD assume CPE will only implement protocols that are in wide deployment (>80% of homes) as of 2016 2. Global Connectivity 6 2.1. Recommendations MUST allow Thread hosts to connect to global IPv4 networks 2.2. Recommendations MUST allow Thread hosts to receive responses from global IPv4 networks within a realistic time window 2.3. Recommendations MUST allow Thread hosts to connect to global IPv6 networks 2.4. Recommendations MUST allow Thread hosts to receive responses from global IPv6 networks within a realistic time window 2.5. Recommendation SHOULD allow Thread hosts to receive unsolicited IPv6 messages from nodes in global IPv6 networks 2.6. Thread hosts MAY be required to register with the Border Router in order to receive unsolicited messages from off-mesh sources 3. Site Connectivity 3.1. Recommendations MUST allow Thread hosts to connect to on-site IPv4 hosts 3.2. Recommendations MUST allow Thread hosts to connect to on-site IPv6 hosts 3.3. Recommendations SHOULD allow on-site IPv6 hosts, such as laptops or phones, to connect to Thread hosts (and run discovery protocols to discover Thread hosts) 4. Security and Firewall 4.1. Recommendations MUST ensure that only ingress traffic enters a Thread network that Thread hosts have expressed interest in 7 Proposed Solution Summary A summary of the proposed solution, in terms of the recommended best practices and protocols for Thread Border Routers, is presented below. More details can be found in the next section “Best Practices” on page 14. Protocols Summary Not Requirement Solution (Protocols) RECOMMENDED OPTIONAL Recommended NAT64, DNS64, IPv4 Global, stateful firewall, IPv4 Site ✔ Self-election via connectivity Thread Network Data DHCPv6-PD, IPv6 Global, ✔ stateful firewall, IPv6 Site Except when only Self-election via connectivity /64 prefix available Thread Network Data Thread MeshCoP Border Commissioning Agent, DNS-SD (for ✔ / Discovery Commissioning) Security for Site Address PCP ✔ Referral Private ✔ Networking VPN (Global) IPv6 Global via ✔ Cellular Allowed when only ND Proxy
Recommended publications
  • SIP Software for Avaya 1200 Series IP Deskphones-Administration

    SIP Software for Avaya 1200 Series IP Deskphones-Administration

    SIP Software for Avaya 1200 Series IP Deskphones-Administration Release 4.4 NN43170-601 Issue 06.05 Standard July 2015 © 2015 Avaya Inc. list of Heritage Nortel Products located at http://support.avaya.com/ All Rights Reserved. LicenseInfo under the link “Heritage Nortel Products” or such successor site as designated by Avaya. For Heritage Nortel Notice Software, Avaya grants You a license to use Heritage Nortel While reasonable efforts have been made to ensure that the Software provided hereunder solely to the extent of the authorized information in this document is complete and accurate at the time of activation or authorized usage level, solely for the purpose specified printing, Avaya assumes no liability for any errors. Avaya reserves in the Documentation, and solely as embedded in, for execution on, the right to make changes and corrections to the information in this or for communication with Avaya equipment. Charges for Heritage document without the obligation to notify any person or organization Nortel Software may be based on extent of activation or use of such changes. authorized as specified in an order or invoice. Documentation disclaimer Copyright “Documentation” means information published by Avaya in varying Except where expressly stated otherwise, no use should be made of mediums which may include product information, operating materials on this site, the Documentation, Software, Hosted Service, instructions and performance specifications that Avaya may generally or hardware provided by Avaya. All content on this site, the make available to users of its products and Hosted Services. documentation, Hosted Service, and the product provided by Avaya Documentation does not include marketing materials.
  • DSL-Based Access Solutions Thomas Martin Session SPL-211

    DSL-Based Access Solutions Thomas Martin Session SPL-211

    SPL_211 © 2001, Cisco Systems, Inc. All rights reserved. 1 Design Principles for DSL-Based Access Solutions Thomas Martin Session SPL-211 SPL_211 © 2001, Cisco Systems, Inc. All rights reserved. 3 Agenda • Digital Subscriber Line Technologies • Subscriber Connection Models • Reaching the Services • Case Studies • Summary, Question and Answer SPL_211 © 2001, Cisco Systems, Inc. All rights reserved. 4 What is Digital Subscriber Line (DSL)? End-User DSL E’net ATM Value-Added Copper Loop Packet Network DSL DSL “Modem” “Modem” • DSL is a pair of “modems” on either end of a copper wire pair • DSL converts ordinary phone lines into high-speed data conduits • Like dial, cable, wireless, and E1, DSL by itself is a transmission technology, not a complete end-to-end solution • End-users don’t buy DSL, they buy services such as high-speed Internet access, intranet, leased-line, voice, VPN, and video on demand SPL_211 © 2001, Cisco Systems, Inc. All rights reserved. 5 DSL Modem Technology DSLDSL ServiceService Max.Max. DataData RateRate AnalogAnalog VoiceVoice Max.Max. ReachReach Down/UplinkDown/Uplink (bps)(bps) SupportSupport (km-feet)(km-feet) Residential VDSL–Very 25M/1.6M25M/1.6M YesYes .9–3,000.9–3,000 High Bit Rate oror 8M/8M8M/8M SOHO ADSL–Asymmetric 8M/1M8M/1M YesYes 5.5–18,0005.5–18,000 G.SHDSL 2.3M/2.3M.2.3M/2.3M. NoNo 8.15–26,0008.15–26,000 Business • Trade-off is reach vs. Bandwidth • Reach numbers imply “clean copper” • Different layer 1 transmission technologies, need a common upper protocol layer to tie them together SPL_211 © 2001, Cisco Systems, Inc.
  • Best Practices for Deploying Ipv6 Over Broadband Access

    Best Practices for Deploying Ipv6 Over Broadband Access

    WHITE PAPER Best Practices for Deploying IPv6 over Broadband Access www.ixiacom.com 915-0123-01 Rev. D, January 2016 2 Table of Contents Introduction ................................................................................................. 4 IPv6 Solutions for Broadband Access......................................................... 4 Translation ................................................................................................... 5 Tunneling ..................................................................................................... 5 Dual-Stack Lite (DS-Lite) ............................................................................ 5 IPv6 Rapid Deployment (6rd) ...................................................................... 6 Dual-Stack ................................................................................................... 8 How Dual-Stack PPP works ....................................................................... 8 Test Requirements ....................................................................................... 9 Testing Tunneling ......................................................................................... 9 Testing Dual-Stack PPP ............................................................................. 11 Conclusion ..................................................................................................12 3 Introduction Service Providers: The IPv6 Bell Tolls for Thee! After more than a decade of forewarning, the IPv4 to IPv6 transition has
  • Using PANA for Mobile Ipv6 Bootstrapping Julien Bournelle, Jean-Michel Combes, Maryline Laurent, Sondes Larafa

    Using PANA for Mobile Ipv6 Bootstrapping Julien Bournelle, Jean-Michel Combes, Maryline Laurent, Sondes Larafa

    Using PANA for mobile IPv6 bootstrapping Julien Bournelle, Jean-Michel Combes, Maryline Laurent, Sondes Larafa To cite this version: Julien Bournelle, Jean-Michel Combes, Maryline Laurent, Sondes Larafa. Using PANA for mobile IPv6 bootstrapping. NETWORKING 2007 : 6th international IFIP-TC6 networking conference on ad hoc and sensor networks, wireless networks, next generation Internet, May 2007, Atlanta, United States. pp.345 - 355, 10.1007/978-3-540-72606-7_30. hal-01328113 HAL Id: hal-01328113 https://hal.archives-ouvertes.fr/hal-01328113 Submitted on 7 Jun 2016 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Using PANA for Mobile IPv6 Bootstrapping Julien Bournelle1, Jean-Michel Combes2, Maryline Laurent-Maknavicius1, Sondes Larafa1 1 GET/INT, 9 rue Charles Fourier, 91011 Evry, France 2 France Telecom R&D, 38/40 rue du General Leclerc, 92784 Issy-Les-Moulineaux, France Abstract One of the current challenge of the Mo- 2 Mobile IPv6 Overview bile IPv6 Working Group at the IETF is to dynami- As it stands in [1], an IPv6 Mobile Node (MN) is cally assign to a Mobile Node its Home Agent, Home uniquely identi¯ed by its Home Address (HoA), and Address and to setup necessary security associations.
  • Configurable Routing in Ad-Hoc Networks

    Configurable Routing in Ad-Hoc Networks

    Configurable Routing in Ad-Hoc Networks Nadine Shillingford and Christian Poellabauer Department of Computer Science and Engineering University of Notre Dame Notre Dame, IN 46556 fnshillin, [email protected] Abstract— The actual use of a wireless ad-hoc network or run across the network, will be unknown a-priori. Further, ad- its operational parameters may be unknown before deployment hoc networks may be accessed by varying numbers of clients or they may change during the life time of a network. This (users), with different applications and differing expectations requires that an ad-hoc network be configurable to the unique needs of a client and that multiple clients can configure the on QoS. Therefore, it will be essential to make configurability network simultaneously. The QoS metric(s) used in the selection and customizability of future ad-hoc networks a key design of routes in an ad-hoc routing protocol can strongly affect the feature. network’s performance. Unfortunately, the majority of existing Toward this end, this work introduces the CMR (Con- routing protocols support only one or two fixed metrics in route figurable Mesh Routing) toolkit which provides an easy-to- selection. We conducted a survey of over 40 routing protocols published from 1994-2007 which indicated that 90% of the use API for ad-hoc networks, allowing applications or users protocols use one or two metrics and only 10% use three to to implement their own routing protocols and QoS metrics. four metrics in route selection. Toward this end, we propose a While our prototype implementation supports four of the most modular routing toolkit for ad-hoc networks, where users and popular QoS metrics, it is easily extensible and we expect that applications can initiate route discoveries that best suit their QoS future versions will cover a large variety of QoS metrics.
  • CS 638 Lab 6: Transport Control Protocol (TCP)

    CS 638 Lab 6: Transport Control Protocol (TCP)

    CS 638 Lab 6: Transport Control Protocol (TCP) Joe Chabarek and Paul Barford University of Wisconsin –Madison jpchaba,[email protected] The transport layer of the network protocol stack 1 Overview and Objectives (layer 4) sits between applications (layers 5-7) and Unlike prior labs, the focus of lab #6 is is on the network (layer 3 and below). The most basic learning more about experimental tools and on ob- capability that is enabled by transport is multiplex- serving the behavior of the various mechanisms that ing the network between multiple applications that are part of TCP. The reason for this is because in wish to communicate with remote hosts. Similar to moving from layer 3 to layer 4, we are moving away other layers of the network protocol stack, transport from the network per se, and into end hosts. Further- protocols encapsulate packets with their own header more, network administrators usually don’t spend a before passing them down to layer 3 and decapsulate lot of time messing around with TCP since there is packets before passing them up to applications. no programming or management interface to TCP The most simple transport protocol is the User on end hosts. The exception is content providers Datagram Protocol (UDP). UDP provides a mul- who may make tweaks in an attempt to get better tiplexing/demultiplexing capability for applications performance on large file transfers. but not much more. Most significantly, UDP pro- In terms of experimental tools, a focus of this vides no guarantees for reliability, which is unac- lab is on learning about traffic generation.
  • Spirent AION

    Spirent AION

    DATASHEET Spirent AION Spirent TestCenter Broadband Access Standard and Advanced Bundles, Carrier • Enhanced Realism—Spirent Ethernet Bundle TestCenter Access test solution Overview emulates real world broadband subscriber behaviors, Triple Play Spirent AION is a flexible delivery platform that enables users to achieve improved services, and failure scenarios deployment and provisioning for all their cloud and network testing needs. It is designed to deliver ultimate flexibility in how Spirent TestCenter platforms are • Improved Testing Capacity— purchased and utilized. accomplish more in less lab space The extended platform combines a wealth of industry-leading test solutions with a with the highest number of emulated flexible licensing architecture to support a wide range of next-generation solution- subscribers and user planes per port based domain applications. and port density AION offers a centralized management hub to help leverage software and hardware • Reduced Test Time—set up tests functionalities across all lab users and locations for a simplified management and quickly and easily to validate decision-making process: system performance in realistic, unstable environments rather than • Flexible purchasing options available via subscription, consumption-based, and perpetual plans, with the ability to license different bandwidth, scale, and protocol bundles. an environment optimized for pure performance • Flexible deployment options offered include cloud-delivery, on-prem, and laptop-hosted licensing services. • Detailed Analysis—Data
  • Qos Support in MPLS Networks

    Qos Support in MPLS Networks

    1 QoS Support in MPLS Networks MPLS/Frame Relay Alliance White Paper May 2003 By: Victoria Fineberg, Consultant [email protected] Abstract MPLS is sometimes used synonymously with QoS, but more accurately, it is a QoS- enabling technology that forces application flows into connection-oriented paths and provides mechanisms for traffic engineering and bandwidth guarantees along these paths. Furthermore, when an MPLS network supports DiffServ, traffic flows can receive class- based admission, differentiated queue servicing in the network nodes, preemption priority, and other network treatment that provide bases for QoS guarantees. The IETF work in this area has been augmented by the MPLS/Frame Relay Alliance Implementation Agreement which extends MPLS to the user-network interface, and thus serves as a foundation for implementing QoS end-to-end. This paper describes various QoS and MPLS mechanisms and analyzes their applicability. 2 Table of Contents 1. Introduction..................................................................................................................3 1.1 QoS Drivers .........................................................................................................3 1.2 Main Definitions ..................................................................................................4 1.3 Necessary Conditions for QoS.............................................................................5 2. Initial QoS and TE Models ..........................................................................................6
  • Serial/IP COM Port Redirector User Guide

    Serial/IP COM Port Redirector User Guide

    Navigation: »No topics above this level« Serial/IP® COM Port Redirector User Guide OEM Edition Quick Start Guide Version 4.9 Serial/IP is a registered trademark of Tactical Software, LLC. Tactical Software is a registered trademark of Tactical Software, LLC. Copyright © 2016 Tactical Software, LLC. www.tacticalsoftware.com This Quick Start Guide describes how to install and configure the Serial/IP Redirector so that the Windows applications can use virtual COM ports to access networked serial devices. Configure the Serial Device Server Make sure that the serial server makes its devices available on a TCP port. Install the Serial/IP Software · Log in as Administrator. · Run the Serial/IP setup program. · Use all default choices. · The Serial/IP Redirector will begin running. Windows will not need to be restarted. Create Virtual COM Ports In the Select Ports window, select one or more virtual COM ports, and then click OK. The Serial/IP Select Ports window Configure a Virtual COM Port Enter the IP Address of the serial device server. Enter the TCP Port Number that it is listening on. If the server requires a login, then select the Use Credentials From checkbox. Then in the drop-down list, select Use Credentials Below and enter the Username and Password. The Serial/IP Control Panel Run Auto Configure Click Auto Configure. In the Auto Configure window, click Start. When it completes, click Use Settings. The correct setting will be made for Connection Protocol. The Serial/IP Auto Configure window Ensure that Firewall Software Permits Connections The Serial/IP setup program will add an exception for Serial/IP in the Microsoft Windows Firewall.
  • Openswitch OPX Configuration Guide Release 3.0.0 2018 - 9

    Openswitch OPX Configuration Guide Release 3.0.0 2018 - 9

    OpenSwitch OPX Configuration Guide Release 3.0.0 2018 - 9 Rev. A02 Contents 1 Network configuration....................................................................................................................................4 2 Interfaces...................................................................................................................................................... 5 Physical ports..................................................................................................................................................................... 5 Fan-out interfaces..............................................................................................................................................................6 Port-channel and bond interfaces....................................................................................................................................7 VLAN interfaces................................................................................................................................................................. 7 Port profiles.........................................................................................................................................................................8 3 Layer 2 bridging............................................................................................................................................10 VLAN bridging...................................................................................................................................................................10
  • ISP Architecture – MPLS Overview, Design and Implementation for Wisps

    ISP Architecture – MPLS Overview, Design and Implementation for Wisps

    www.iparchitechs.com 1-855-MIKROTI(K) ISP Architecture – MPLS Overview, Design and Implementation for WISPs. KEVIN MYERS, NETWORK ARCHITECT / MANAGING PARTNER MTCINE #1409 MIKROTIK CERTIFIED TRAINER •Kevin Myers, Network Architect • Jackson, Mississippi – United States • 18 + years in IT, Network Architecture and Engineering • Areas of Design Focus: •MikroTik integration with large multi-vendor networks •Design/Implement/Operate BGP/MPLS/OSPF Wireline and WISP service provider networks •Design/Implement/Operate Data Center (Enterprise and Cloud) networks • Certifications • MTCINE #1409 & MikroTik Certified Trainer • MikroTik – MTCWE, MTCUME, MTCRE, MTCTCE, MTCNA • Cisco/Microsoft – CCNP, CCNA, MCP •www.iparchitechs.com •Global Leaders in MikroTik Design and Engineering •#1 ranked MikroTik consulting firm in North America •The most successful MikroTik global integrator – we bill thousands of hours in MikroTik engineering across 6 continents. •The first consulting firm to offer 24/7 MikroTik technical assistance with enterprise level SLAs •Operate at large scale supporting networks with tens of thousands or routers, switches, firewalls, etc •www.iparchitechs.com •Our Services •Global Professional Services – Consulting for Design, Engineering, Integration and Operations •Fully Managed Network Services - per rack unit support for full network management and monitoring •24/7 support contracts per device – support all MikroTik devices with 24/7 TAC support and 4 hour SLAs. • MultiLingual Support in: English, Français, Polski, Español MPLS – What is it? • Theory: Briefly introduce the MPLS protocol and how it works in conjunction with existing L2/L3 networks • Design: Discuss an MPLS architecture and preparing your WISP for implementing MPLS. • Business Justification: Identify the business and financial use case for implementing MPLS in a WISP.
  • Ipv6 in Broadband Networks MR-244

    Ipv6 in Broadband Networks MR-244

    IPv6 in Broadband Networks MR-244 January 2011 Agenda 1. Introduction to the Broadband Forum 2. Business drivers for IPv6 and IPv4 exhaustion 3. Key IPv6 attributes and deployment challenges 4. IPv6 strategies for broadband access to support Internet access and new services 5. Summary 2 IPv6 in Broadband Networks Tutorial Contributors Christophe Alter – France Telecom Salman Asadullah – Cisco David Allan – Ericsson Michel Borgne – France Telecom Dave Christophe – Alcatel-Lucent Guillaume Gottardi – Cisco Michael Hanrahan – Huawei Christian Jacquenet – France Telecom David Kessens – NSN Suresh Krishnan – Ericsson Roberta Maglione – Telecom Italia Drew Rexrode – Verizon 3 We are the Broadband Forum http://www.broadband-forum.org The Broadband Forum is the central organization driving broadband solutions and empowering converged packet networks worldwide to better meet the needs of vendors, service providers and their customers. We develop multi-service broadband packet networking specifications addressing interoperability, architecture and management. Our work enables home, business and converged broadband services, encompassing customer, access and backbone networks. 4 The BroadbandSuite Goals and Focus The BroadbandSuite is broken down into three major domains: BroadbandManagement – Goal – enhance network management capabilities and enable an intelligent, programmable control layer that unifies diverse networks – Focus - empower service providers to deliver and efficiently maintain personalized services that enhance the