622Mb Edgeless L2TP BT Central Product For BT IPstream. Interface Characteristics

Transcription

1 SIN 412 Issue 3.6 January 2014 Suppliers' Information Note For The BT Network 622Mb Edgeless L2TP BT Central Product For BT IPstream Interface Characteristics Each SIN is the copyright of British Telecommunications plc. Reproduction of the SIN is permitted only in its entirety, to disseminate information on the BT Network within your organisation. You must not edit or amend any SIN or reproduce extracts. You must not remove BT trade marks, notices, headings or copyright markings. This document does not form a part of any contract with BT customers or suppliers. Users of this document should not rely solely on the information in this document, but should carry out their own tests to satisfy themselves that terminal equipment will work with the BT network. BT reserves the right to amend or replace any or all of the information in this document. BT shall have no liability in contract, tort or otherwise for any loss or damage, howsoever arising from use of, or reliance upon, the information in this document by any person. Due to technological limitations a very small percentage of customer interfaces may not comply with some of the individual characteristics which may be defined in this document. Publication of this Suppliers' Information Note does not give or imply any licence to any intellectual property rights belonging to British Telecommunications plc or others. It is your sole responsibility to obtain any licences, permissions or consents which may be necessary if you choose to act on the information supplied in the SIN. Those BT services marked indicates it is a registered trade mark of British Telecommunications plc. Those BT services marked indicates it is a trade mark of British Telecommunications plc. British Telecommunications plc Registered Office 81 Newgate Street LONDON EC1A 7AJ Registered in England no

2 CONTENTS 1 INTRODUCTION DEFINITIONS: SERVICE OUTLINE CUSTOMER INTERFACE SPECIFICATION TRANSPORT IP LAYER L2TP LAYER PPP LAYER Ethernet Frame Size RADIUS Protocol Session Timeouts End User CPE Requirements END USER IP LAYER NETWORK TERMINATING EQUIPMENT POLICING (TRAFFIC LIMITING) ROUTING Service Details SP Information Required Sample Configuration OSPF option FURTHER INFORMATION / CONTACT POINTS REFERENCES ABBREVIATIONS HISTORY FIGURES FIGURE 1 OUTLINE ARCHITECTURE WITH THE 622MB EDGELESS L2TP PRODUCT... 4 FIGURE 2 PPP STAGES WITH THE 622MB EDGELESS PRODUCT... 8 FIGURE 3 DUAL NTE WITH DUAL SP ROUTERS FIGURE 4 DUAL NTE WITH MULTIHOMED SP ROUTER FIGURE 5 DUAL NTE WITH DUAL SP ROUTERS, OSPF OPTION FIGURE 6 DUAL NTE WITH MULTIHOMED SP ROUTER, OSPF OPTION TABLES TABLE 1 EDGELESS L2TP PASSTHROUGH BT CENTRAL AVAILABLE BANDWIDTHS... 6 TABLE 2 RADIUS ACCESS REQUEST ATTRIBUTES... 9 TABLE 3 RADIUS ACCESS RESPONSE ATTRIBUTES SIN 412 Issue 3.6 British Telecommunications plc Page 2 of 20

3 1 Introduction This Suppliers' Information Note (SIN) describes the characteristics of the 622Mb Edgeless L2TP BT Central product. The BT Central product provides a connection from the BT Network to the Customer and is a necessary component for the end to end connection of BT BT IPstream Office, BT IPstream Home, BT IPstream Max, BT IPstream Max Premium or BT IPstream Symmetric products to the Customer. The BT Central products are available for use by Customers (including OLOs, and Business Customers) to connect a number of End Users to their network. This document provides information for Manufacturers, Suppliers and Customers Independent Service Providers (SPs), Other Licensed Operators (OLOs), Other Network Operators (ONOs), and Corporate Businesses. Please note: BT Central and Central Plus products are no longer available for new supply and will be retired nationally from 31 July For further information please see briefing reference BB , available via btwholesale.com. 1.1 Definitions: Customer: The Service Provider (SP) or Business Customer (BC) who purchases the BT IPstream service from BT and sells or provides it to End-Users. End User: The person using their PC to connect to a SP/BC s IP network via the BT IPstream service. L2TP Passthrough: passing the L2TP tunnels to the customer to allow termination of the tunnels on the customers own equipment, rather than BT provided equipment. SIN 412 Issue 3.6 British Telecommunications plc Page 3 of 20

4 1.2 Service Outline End User Equipment N T E BT IP Network NTP (Customer) End User Equipment N T E BT LAC BT Remote LAC Access Server L2TP Tunnel Concentrator L2TP Tunnel Concentrator LTS Cluster N T E Customer Network End User Equipment N T E N T E Customer RADIUS NTP (End User) ADSL access to BT network L2TP PPP IP RADIUS NTE Interface Ethernet Interface: 1000BaseSX Optical Fibre Gigabit Ethernet Payload (L2TP over IP) L2TP Figure 1 Outline architecture with the 622Mb Edgeless L2TP product The 622Mb Edgeless L2TP BT Central connection is a variant of the standard BT Central that allows the Customer to have direct access to their End Users' PPP sessions. End User PPP sessions are presented to the Customer in L2TP tunnels. The BT IPstream End User access products remain unaltered. The 622Mb Edgeless L2TP product provides connectivity between the Customer s premises and BT s high speed data network, via a pair of NTE routers which will be located on the customer s premises. L2TP tunnels will be passed to the customer s site across a pair of SHDS circuits. One of the SHDS circuits will be the main, and the other will be the standby connection. The SHDS fibres will normally be diversely routed but where this is not possible (for example where the diverse route exceeds the duct route limit of SHDS) the customer will be informed. BT will pass end user traffic to the customer across the main SHDS circuit, if available. Customers should ensure that traffic passed back into the BT network is also passed across the main circuit. In the event of a network outage which affects the main SHDS circuit, the traffic will be passed to the customer across the standby. SIN 412 Issue 3.6 British Telecommunications plc Page 4 of 20

5 The product will include the ability to deliver 155Mbps initially, then 'flex' the customer service up to 622Mbps in 155Mbps increments. A full list may be seen in Table 1. A five working day lead-time will be required to perform this bandwidth increase. Higher bandwidths may also be available in the future. The Flexing will be implemented by building the service for full capacity from the outset, and throttling/policing the bandwidth to the requested customer bandwidth, then using configuration to increase the bandwidth on receipt of a customer request. The method used to un-throttle the service will allow the bandwidth to be increased within a 5 working day lead-time. The 622Mb Edgeless L2TP BT Central will support the use of domain name option functionality such as One to Many 1. BT will support a mixture of 155Mbits/s L2TP Passthrough and 622Mbits/sec Edgeless L2TP passthrough however customers should note that such a mix will cause an imbalance in traffic between the two central types. This imbalance is due to the different numbers of LTSs used per unit of central bandwidth within the two central designs - as new sessions are evenly distributed over LTSs within a One to Many group. This imbalance is somewhat offset by the increase of bandwidth offered by 622Mbits/sec L2TP central. The 622Mbit/sec design offers a 23% improvement in bandwidth over the equivalent number of 155Mbit/sec BT centrals. The 155Mbps design uses 2 LTSs and provides approximately 56.5Mbits/sec (of end user IP traffic) per LTS. The 622Mbits/sec design uses a total of 12 LTSs and provides 46.3Mbits/sec (of end user IP traffic) per LTS. Consequently, when mixing 155Mbps and 622Mbps centrals in the same one to many group the 155Mbits/sec centrals will be approximately 18% under-utilised i.e. when traffic has reached the full rating of the 622Mbps central the 155Mbps centrals will have reached only 82% of their rated capacity. Due to the traffic balancing algorithm used on individual LTS routers, it is recommended that customers provide multiple L2TP tunnel endpoints within their network. Multiple end points prevent the algorithm from favouring a single link between the LTS and FER which would otherwise result in link over utilization and packet loss at the LTS. It is therefore suggested that in excess of 3 tunnel end points be provided by the ISP to ensure the best operation of the 622 LTS cluster. Note: that the domain nameless option cannot be used with the 622Mb L2TP Edgeless BT Central product. Refer to SIN 329 [1] for additional information on other BT Central products, or the available domain name options that may be used. 1 i.e. where a single domain name is mapped across multiple BT Central connections. SIN 412 Issue 3.6 British Telecommunications plc Page 5 of 20

6 Both of the current BT platform test accounts, and will continue to be supported for the 622Mb Edgeless L2TP product. The test account will be terminated at the RAS. The test account will terminate on the BT LTS. In addition to the standard platform test accounts, it will be possible for operational duties within BT to terminate test tunnels at the edge of the BT network using the test router that will be installed in addition to the NTE devices. 2 Customer Interface Specification The Ethernet interface offered on this product presents end user IP over PPP over L2TP over UDP over IP over Ethernet, delivered on 1000BaseSX optical fibre [10]. The product is part of the BT Central product portfolio, and is available at the rates specified in table 1 below. Higher rates may be available at some point in the future. Approximate SDH Equivalent Rate (Policed at IP layer) Interface Presentation Maximum Simultaneous Sessions Typical Maximum End User IP Throughput Downstream (see Note 3) Total Maximum End User IP Throughput (Upstream + Downstream) (see note 4) 155Mbits/s (Policed) Gigabit Ethernet Mbit/s 209 Mbit/s 310Mbits/s (Policed) Gigabit Ethernet Mbit/s 417 Mbit/s 465Mbits/s (Policed) Gigabit Ethernet Mbit/s 626 Mbit/s 622Mbits/s (Policed) Gigabit Ethernet Mbit/s 836 Mbit/s Table 1 Edgeless L2TP Passthrough BT Central available bandwidths Notes: 1. The BT Central products must not be overbooked in terms of the numbers of sessions. Additional End User s sessions will not be presented to the Customer when the number exceeds the maximums given in Table RADIUS traffic for PPP session set-up will be excluded from bandwidth policing. SIN 412 Issue 3.6 British Telecommunications plc Page 6 of 20

7 3. The typical maximum IP throughput downstream figures show the indicative IP throughput after protocol overheads have been removed. The protocols in operation here are PPP, L2TP and UDP/IP. The actual values will vary depending on the size of the IP packets and mixture of the different sizes of the IP packets transmitted. The IP throughput downstream and upstream will be reduced if the total upstream and downstream traffic exceeds the total IP throughput performance of the BT Central (see Note 4). 4. The total maximum IP throughput figures show the indicative limit of the sum of Upstream and Downstream traffic supported by the BT Central. The actual values will vary depending on the size of the IP packets and mixture of the different sizes of the IP packets transmitted Please refer to SIN 329 [1] for additional information. 2.1 Transport IP Layer This layer must conform to RFC 791 [6]. The routing protocols used are described in sections 2.7 and 2.8. The MTU size associated with this layer must be at least 1542 to allow 1500 byte packets to be sent un-fragmented to the BT-RAS and hence improve the performance of the BT IPstream service received by End User s. The use of an MTU size of at least 1542 bytes on this interface will be mandatory. BT however recommends Customers use a MTU size of 1600 bytes on this interface to allow for future enhancements. BT will use a MTU size of 1600 bytes on this interface. See section for the impact of this requirement on the Ethernet Layer. 2.2 L2TP Layer The L2TP Tunnel Switch (LTS) can deliver dynamic L2TP tunnels to the Customer s network without being constrained by the four tunnel end point limit that the current 155Mb L2TP Passthrough BT Central has in place. The 622Mbits/sec L2TP design supports a maximum of 500 L2TP tunnel endpoints within the customer s network. It is up to the customer to decide how many end points they actually wish to use. These end points would usually be expected to be LNSs or LTSs in either case the Customer s equipment terminating tunnels must conform to RFC 2661 [5]. End user sessions will be passed to the customer using information retrieved from the customer s own RADIUS during session authentication. The customer RADIUS can examine the username and domain name attribute that will be part of the RADIUS access request, and steer sessions to their own LTS or LNS devices as appropriate. A maximum concurrent session limit will be enforced across all the tunnels leaving the BT LTSs dependent upon the purchased bandwidth rate. Refer to table 1 for these maximum session limits. 2.3 PPP Layer The Customer s terminating equipment must support PPP conforming to RFC 1661 [4], RFC 1994 [7] and RFC 1877 [9]. Authentication using CHAP (Challenge Handshake Authentication Protocol) will be requested during the Link Establishment phase. SIN 412 Issue 3.6 British Telecommunications plc Page 7 of 20

8 End Users NTP NTE BT ATM Network Request Tunnel Info. (5) BT Platform RADIUS LAC Tunnel info (6) : Local Name (LAC) Tunnel Password Tunnel Type LTS IP Address. BT IP Network BT L2TP Tunnel Concentrator LTS (12) Access Request. BT SHDS Network Customer RADIUS (13) Access Response. N T E NTP (19) Access Request. Customer LNS Customer RADIUS (20) Access Response. Call Setup (1) Tunnel CHAP challenge (7) Tunnel CHAP challenge (14) PPP LCP Negotiation (2) Tunnel CHAP response (8) Tunnel CHAP response (15) User CHAP challenge (3) User CHAP Response (4) Tunnel CHAP success (9) Tunnel Ack (10) Tunnel CHAP success (16) Tunnel Ack (17) Service Provider / Customer PPP LCP forwarded (11) PPP LCP forwarded (18) CHAP success (21) PPP IPCP Negotiation (22) Figure 2 PPP Stages with the 622Mb Edgeless product Messages [1 and 2] are sent as a result of the End User initiating a PPP session. The End User device and BT LAC will negotiate PPP LCP parameters. The RAS requires the full username and therefore performs a User CHAP Challenge [3 and 4]. Following this, the BT LAC initiates a dialogue with the BT Platform RADIUS [5 and 6]. As a result of determining the BT Central connection destination, the BT LAC attempts to set up a tunnel to the L2TP Tunnel Switch serving the Customer [7 to 10]. Upon successful set up of a tunnel between the BT LAC and the LTS, the LAC will forward the LCP parameters it has negotiated with the End User to the LTS. The LTS will send an access request message to the Customer RADIUS, which should respond with tunnel set up information [12 and 13]. The LTS then attempts to set up a tunnel to the Customer s termination point (shown as an LNS in Figure 2) [14 to 17]. After the tunnel has been established the PPP LCP parameters that were initially negotiated between the End User device and BT LAC are forwarded to the LNS [18]. If the LNS is unhappy with these PPP LCP parameters it may renegotiate LCP with the End User device, this is not depicted in Figure 2. A lookup is performed with the Customer RADIUS to authenticate the PPP session [19 and 20]. A successful CHAP authentication will result in a CHAP success message being returned to the End User [21]. At this point the IPCP negotiation process initiates which will assign layer 3 protocol information to the End User, such as IP and DNS addressing [22]. Note: Within diagram 2, two customer RADIUSs have been shown. The customer may have a single RADIUS performing both tunnel set-up and end user authentication functions. SIN 412 Issue 3.6 British Telecommunications plc Page 8 of 20

9 See SIN 374 [11] for the effects of using PPPoE with L2TP Passthrough Services Ethernet Frame Size A minimum Ethernet frame size of 1560 bytes must be supported by the customer. This is larger than the normal Ethernet frame size of 1518 bytes and is needed to support L2TP encapsulation without fragmentation, as there is an additional 42 bytes of L2TP overhead when a 1500 byte IP MTU is used RADIUS Protocol Tables 2 and 3 show the access request and access response RADIUS attributes that will be used for the 622Mb edgeless L2TP product. These attributes must be supported and used by the customer RADIUS. IETF RADIUS attributes must be used, not vendor specific attributes. No RADIUS accounting data will be provided. Accounting data can be collected from the LNS if required. If the connection to the customers RADIUS is lost, end user sessions will be terminated inside the LTS cluster located on BT premises. Access control lists will be applied to end user session terminated in this way to limit internet access to a test web page informing the end user of potential problems. No Attribute Name Attribute Comment 1 User-Name As entered by user 3 CHAP-Password Users password (encrypted) 4 NAS-IP-Address LTS loopback address 5 NAS-Port LTS local logical port 6 Service-Type (2) Framed 7 Framed-Protocol (1) PPP 61 NAS-Port-Type (5) Virtual Table 2 RADIUS access request attributes SIN 412 Issue 3.6 British Telecommunications plc Page 9 of 20

10 No Attribute Name Attribute Comment 6 Service-Type (2) Framed (Optional) 7 Framed-Protocol (1) PPP (Optional) 25 Class String (Optional) 64 Tunnel-Type (3) L2TP 65 Tunnel-Medium-Type (1) IPv4 67 Tunnel-Server- Endpoint LNS IP address (Only dotted decimal notation supported) 69 Tunnel-Password Password (Optional - can be configured in BT LTS) 82 Tunnel-Assignment-ID String (Optional Multiple tunnels between BT LTS and LNS) 83 Tunnel-Preference Integer (Optional used in conduction with Tunnel-server-Endpoint) 90 Tunnel-Client-Auth-ID Name (Optional default can be configured on BT LTS) Table 3 RADIUS access response attributes Session Timeouts The customer must enforce a minimum session timeout such that all established sessions will last for a minimum of two hours (7200 seconds) for both the PPP idle and PPP session timeouts. An end user may choose to terminate their session at any time. This minimum timeout period ensures that the BT network is not overburdened with the churn of PPP sessions. BT will monitor the rate of session set-ups to ensure that this criterion is met End User CPE Requirements BT end user CPE requires an IP address to be returned from the customer LNS during the set-up phase of the PPP session. BT end user CPE requires primary and secondary DNS server IP addresses to be returned from the customers LNS during the PPP IPCP phase [4]. This complies with the BT IPstream service as defined in SIN 329 [1]. 2.4 End User IP Layer The end user IP layer must conform to RFC 791 [6]. SIN 412 Issue 3.6 British Telecommunications plc Page 10 of 20

11 2.5 Network Terminating Equipment The Customer must have sufficient space available to accommodate the SHDS termination devices, and the NTEs delivering the end user traffic to their equipment. The NTEs used for the 622Mb product have the following dimensions: Ethernet interface Pre November 2007: 2x Cisco G switches. Dimensions (H x D x W) = 6.68 x x cm From November 2007 onwards: * 2x Cisco 3750 switches. Dimensions (H x D x W) = 4.39 x 44.5 x 37.3 cm SHDS NTEs 2x SHDS Termination devices Dimensions (H x D x W) = 4.5 x 22.0 x 48.2 (with mounts) cm The SHDS devices fit into a standard 19 inch rack, although an additional 80mm depth is required for the mains leads which protrude from the back of the device. The SHDS management is done from the BT end of the circuit so there is no requirement to site an ISDN TA. Each NTE fits within a 300mm or 600mm deep ETSI equipment rack conforming to ETS [2]. Each NTE is locally powered, and will require a local main 50Hz AC supplies fused as 20 amps. Four power supplies will be required (2x SHDS devices, 2x NTEs). It is recommended that this power is supplied from two different sources, i.e. SHDS1 and NTE1 powered from source 1 and SHDS2 and NTE2 powered from source 2. This means that the failure of one of the supplies will not effect both Ethernet deliveries. As power supplies can vary slightly in output voltage and characteristics, the NTE will function with Customer provided power supplies, which are in accordance with the British Telecom Network Requirement, (BTNR) 2511 [3]. 2.6 Policing (Traffic Limiting) Summary of Policing for the 622 Mb Edgeless L2TP product: * The change of NTE is due to End of sale of the original 3550 NTE some stock of 3550s may exist that allows 622M centrals to continue to be provisioned with this NTE beyond Nov 2007 SIN 412 Issue 3.6 British Telecommunications plc Page 11 of 20

12 A strict Policer is used; any IP traffic exceeding the defined maximum IP throughput will be dropped. The Policer will be applied to the cumulative IP traffic flowing through both NTEs to/from the customer; the overall Policer limit is enforced regardless of how the 2 links are used. The Policer will be symmetrical in nature; the same policing limit will be applied in both upstream and downstream directions. Policing is applied to the outer IP layer the same policing values are applied to the 622Mbit/sec L2TP passthrough and 622Mbps Home Gateway designs thus for L2TP customers there will be lower usable end user IP throughput. This is also consistent with the cluster design used for both the L2TP and Home Gateway variants where the routers in the cluster have similar outer layer IP throughput in LTS or LNS mode. RADIUS traffic will travel across the BT Central to the customer, but will not be policed by BT. 2.7 Routing Service Details The following diagrams illustrate the preferred connection topologies. The topology shown in Figure 3 provides the SP with greatest amount of resilience. EBGP (multihop) MED = 50 OSPF Area 300 Default Route Metric = 120 Rest of BT Network FER1 Gig 802.1Q Link (VLAN - not a physical link) NTE1 Backup Default Route Metric = 150 GigE SP1 ISP Network FER2 Gig NTE2 GigE Default Route Metric = 120 EBGP (multihop) MED = 100 SP2 BT Network Boundary Figure 3 Dual NTE with Dual SP routers SIN 412 Issue 3.6 British Telecommunications plc Page 12 of 20

13 EBGP (multihop) MED = 50 OSPF Area 300 Gig NTE1 Default Route Metric = 120 Rest of BT Network FER1 FER Q Link (VLAN - not a physical link) Gig NTE2 Bac kup De fault Route M etric = 150 GigE GigE Default Rout e Metric = 120 EBGP (multihop) MED = 100 SP1 BT Network Boundary ISP Network Figure 4 Dual NTE with Multihomed SP Router The service provider will connect a router to each NTE. The use of a switch or LAN between the SP router(s) and the NTEs is not permitted. 1. The NTEs SP facing interfaces, the 802.1Q link and the SP interfaces are configured with static routes. 2. A Static Default route will be configured on each NTE pointing to each SP router. 3. A Backup Static Default route is configured between the NTEs over an 802.1Q (VLAN) link. Customers should note that there is no direct physical connection between the two NTE routers capable of taking traffic. 4. BT s private BGP AS for 622Mbits/sec is Via the ebgp peering the SP routers will learn summary routes to the Pool of addresses assigned to the 622Mbits/sec cluster. The routes learned by SP2 will have their MED set to 100 while the routes learned by SP1 will have their MED set to 50 (preferred). It is highly recommended that the SP honour the MED value and route accordingly. Note : The physical link between the NTE s shown in Figure 3 & Figure 4 is not used for End User traffic. It is present to allow BT to access & manage an NTE if the link from the FER to the NTE fails (management will be via the other FER to NTE link and the physical link between the NTE s). SIN 412 Issue 3.6 British Telecommunications plc Page 13 of 20

14 2.7.2 SP Information Required To allow the routing to operate correctly, the following information must be provided by the customer to BT: BGP AS number (a private AS number is acceptable but it must not equal 65500). Two IP addresses and corresponding mask to assign to each SP facing interface, each must reside in a separate network. Two Next Hop interface IP addresses corresponding to the IP address of the directly connected SP routers. Optional BGP password Sample Configuration The following configuration refers to the topology shown in Figure 3. Sample BGP configuration for SP1 follows. router bgp no synchronization neighbor <IP-BGP-PEER1> remote-as neighbor <IP-BGP-PEER1> password <password> neighbor <IP-BGP-PEER1> ebgp-multihop 255 neighbor <IP-BGP-PEER1> update-source <INTERFACE1> no auto-summary Sample BGP configuration for SP2 follows. router bgp no synchronization neighbor <IP-BGP-PEER2> remote-as neighbor <IP-BGP-PEER2> password <password> neighbor <IP-BGP-PEER2> ebgp-multihop 255 neighbor <IP-BGP-PEER2> update-source <INTERFACE2> no auto-summary SIN 412 Issue 3.6 British Telecommunications plc Page 14 of 20

15 2.7.4 OSPF option EBGP (multihop) FER1 OSPF area 300 Gig NTE1 OSPF area 400 GigE SP1 Rest of BT Network CP Network Gig GigE FER2 NTE2 SP2 EBGP (multihop) BT network boundary Figure 5 Dual NTE with Dual SP Routers, OSPF option EBGP (multihop) FER1 OSPF area 300 OSPF area 400 Gig NTE1 Rest of BT Network GigE GigE SP1 CP Network Gig FER2 NTE2 EBGP (multihop) BT network boundary Figure 6 Dual NTE with Multihomed SP Router, OSPF option SIN 412 Issue 3.6 British Telecommunications plc Page 15 of 20

16 The OSPF (Open Shortest Path First) option is designed to improve the resilience of the 622M service by introducing an OSPF process and area into the 622M central between the NTE and SP routers. This prevents the black holing of IP traffic in the event of an NTE or SP router crash that leaves the NTE to SP link active. For downstream traffic, the SP routers will route to the attached NTE interface using OSPF to maintain link state. For upstream traffic, the SP will inject a default route into the new area to provide the same link state information for the NTE default route to the SP. Optionally, loopback addresses can be applied to the NTEs; these can be either SP or BTW provided. The advantage of applying loopback addresses is that if a SP facing interface fails on the NTE, the loopback address will still be reachable via the second NTE and the back to back link between the NTEs. If the loopback addresses are to be applied, the CP should configure static summary routes for the LTS loopback addresses with a next hop of the NTE loopback address. The loopback addresses are advertised into OSPF by the NTEs, providing the required link state. The new OSPF process is applied in addition to the EBGP process running between the 622M central FERs and the SPs routers. The OSPF process can be applied to existing, active 622M centrals without affecting service. OSPF area 400 will be used by default, but a different value can be used if this value clashes with the value used within the SPs network. The OSPF hello interval is set to 2 seconds, the OSPF dead interval is 6 seconds. 3 Further Information / Contact Points For further information on the commercial aspects of this service, or the services that can be provided over the 622Mbits/sec L2TP BT Central, please refer to: Your BT Account Manager BT Wholesale web site: If you have enquiries relating to this document, then please contact: help@sinet.bt.com 4 References SIN 412 Issue 3.6 British Telecommunications plc Page 16 of 20

17 [1] SIN 329 BT Broadband IP Products Interface Specification [2] ETS Equipment Engineering (EE); European telecommunications standard for equipment practise [3] BTNR 2511 Interface of telecomms equipment with a normal 48 V negative dc power supply. [4] RFC The Point-to-Point Protocol (PPP) [5] RFC Layer Two Tunnelling Protocol "L2TP" 1994 Latest Issue [6] RFC 791 Internet Protocol: DARPA Internet Program Protocol 1981 [7] RFC PPP Challenge Handshake Authentication Protocol (CHAP) [8] 622Mb Home Gateway based Central SIN 329 Addendum March 03 [9] RFC PPP Internet Protocol Control Protocol Extensions for Name Server Addresses Dec 1995 [10] SIN Gigabit Ethernet for the BT Network - Interface Characteristics Jul-00 [11] SIN L2TP Interface For BT IPstream, Interface Characteristics RFC documents are available from: SINs, SPINs and STINs are available from: SIN 412 Issue 3.6 British Telecommunications plc Page 17 of 20

18 5 Abbreviations Acronym AC ATM BC BGP BT BTNR CDN CHAP CPE DNS ebgp ETS ETSI EU IEEE IP ISP IVV&T L2TP LAC LCP LES1000 LNS LTS MTU NTE OLO ONO OSPF PC PPP RADIUS RAS RFC SDH SDSL SHDS SIN Expansions Alternating Current Asynchronous Transfer Mode Business Customer Border Gateway Protocol [IETF] British Telecommunications plc BT Network Requirement [BT] Call Disconnect Notification Challenge Handshake Authentication Protocol [IETF] Customers' Premises Equipment Domain Name System/Server [IETF] external Border Gateway Protocol European Telecommunications Standard [ETSI] European Telecommunications Standards Institute End User [BT] Institute of Electronic and Electrical Engineers [USA] Internet Protocol [IETF] Internet Service Provider Integration, Verification, Validation and Testing Layer 2 Tunnelling Protocol [IETF] L2TP Access Concentrator [Cisco] Link Control Protocol [IETF] SHDS Circuit L2TP Network Server [Cisco] Layer 2 Tunnelling Protocol (L2TP) Tunnel Switch Maximum Transmission Unit Network Termination Equipment Other Licensed Operator Other Network Operator Open Shortest Path First protocol [IETF] Personal/Portable Computer Point-to-Point Protocol [IETF] Remote Authentication Dial In User Service [IETF] Remote Access Server Request for Comment [IETF] Synchronous Digital Hierarchy [ITU-T] Symmetric Digital Subscriber Line Short Haul Data Service [BT] Supplier Information Note [BT] SIN 412 Issue 3.6 British Telecommunications plc Page 18 of 20

19 SP SPIN STIN STM-1 UDP Service Provider Service Provider Industry Notification [BT] Suppliers' Trial Information Note Synchronous Transport Module Level 1 (155 Mbit/s) User Datagram Protocol [IETF] 6 History Issue Date Details of Change STIN 412 Document first published as a STIN. April 2003 Issue 1.0 SIN 412 September 2003 Publication of SIN Issue 1.0 SIN 412 Issue 2.0 July 2005 Notification given of service withdrawal in the third quarter of SIN 412 Issue 3.0 SIN 412 Issue 3.1 SIN 412 Issue 3.2 SIN 412 Issue 3.3 SIN 412 Issue 3.4 July 2005 Correction (by removal) of the erroneous notification given in issue 2.0 of service withdrawal in the third quarter of February 2006 Typographical error corrected in clause April 2006 April 2008 May 2008 Maximum simultaneous sessions increased from to in Table 1 for 622Mbit/s product. References to BT IPstream S and BT IPstream 500 have been removed following their withdrawal. Also text has been added to section 2.5 to cover new NTE. Section added to illustrate the OSPF (Open Shortest Path First) solution where the Service Provider has a single router. Also editorial amendments for clarification. Issue 3.5 September 2010 Editorial clarification to Section 5 and to Contact points Issue 3.6 January 2014 Introduction amended to advise of retirement of Central products nationally by 31 July We would be grateful if you would spend a few minutes to complete an online customer satisfaction form at SIN 412 Issue 3.6 British Telecommunications plc Page 19 of 20

20 END SIN 412 Issue 3.6 British Telecommunications plc Page 20 of 20