idnits 2.17.1 draft-ietf-udlr-pppoe-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 4 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 1) being 70 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 7 instances of too long lines in the document, the longest one being 10 characters in excess of 72. ** There are 23 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2001) is 8197 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 3077' is mentioned on line 62, but not defined == Unused Reference: 'UDLR' is defined on line 191, but no explicit reference was found in the text == Unused Reference: 'PPPoE' is defined on line 195, but no explicit reference was found in the text == Unused Reference: 'GRE' is defined on line 199, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2516 (ref. 'PPPoE') Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT "Network Working Group" G. Chanteau 2 Y. Codaccioni 3 V. Faineant 4 Document: draft-ietf-udlr-pppoe-00.txt France Telecom 5 Expires: April 2002 November 2001 7 Using PPPoE with LLTM Mechanism 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance 13 with all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This memo describes the use and the configuration of the PPPoE over a 33 UniDirectionnal Link such as satellite network. This document explains 34 the advantages of the PPPoE and LLTM in such architecture. 36 Table of Contents 38 Status of this Memo .............................................. 1 39 Abstract ......................................................... 1 40 1. Introduction ................................................... 2 41 2. Network architecture ........................................... 2 42 2.1 Equipments description ......................................... 3 43 2.2 Connections description ........................................ 3 44 2.3 Multicast....................................................... 3 45 3. Advantages ..................................................... 4 46 4. Evolutions .................................................... 5 47 4.1 Multi-receiver connectivity .................................... 5 48 5. References .................................................... 6 49 6. Author's Addresses ............................................ 6 50 7. Full copyright statement ...................................... 7 52 1. Introduction 54 The initial idea was to create a real satellite local loop where a 55 satellite broadband Internet access can replace a terrestrial one 56 in areas that are non covered by terrestrial high speed Internet 57 access such as ADSL. This architecture remains open and in order 58 to provide the same type of services than in ADSL networks, an 59 interconnection with a Broadband Access Server (BAS) is needed. 60 This interconnection uses the PPPoE (PPP over Ethernet). 62 This document explains the advantages of the PPPoE and LLTM [RFC 3077] 63 in such a satellite Local Loop : compatibility with all IP world and 64 performances equivalent to ADSL. It also shows the possible 65 evolutions of this architecture. 67 2. Network architecture 69 Unidirectional Link 70 -------------<----------- 71 | | 72 | | 73 | | 74 | | 75 | | 76 \|/ . 77 . /|\ 78 | | 79 --------- --------- -------- 80 Ethernet | PPPoE/| IP Networks | LLTM | PPPoE | BAS | 81 -------| LLTM |-------->------|Server |---------| | 82 | Router| | | | | 83 | --------- --------- -------- 84 | ____ | 85 |--|PC| | 86 | ---- -------- 87 | ____ LAN | ISP | 88 |--|PC| -------- 89 | ---- 91 Figure 1 : Connectivity to a BAS via PPPoE/LLTM 93 In the Figure 1, the Connections without any arrow are 94 bidirectionnal. 96 2.1. Equipments description 98 Here are the description of the main equipments of this 99 architecture : 101 - the end user is a PC on a LAN. 102 It integrates an Ethernet card. 104 - the satellite terminal is a router with an LLTM client 105 (implementing the RFC 3077). 106 It integrates one satellite reception card, one Ethernet card 107 and one bidirectional interface connected to the Internet. 109 Firstly, it transports the traffic from the end users to 110 the Internet via the return channel which can be either 111 satellite or terrestrial. 113 Secondly, it receives traffic from the DVB channel 114 (previously coming from the Internet) via its DVB interface 115 and deliver it to the end users. 117 - the LLTM server (implementing the RFC 3077) is acting as 118 an Ethernet bridge. 120 This is the endpoint of the GRE tunnel where traffic is 121 encapsulated and decapsulated. The LLTM server is 122 directly connected to a BAS. 124 - the BAS (Broadband Access Server) manages the PPPoE connection. 125 The PPPoE can end into the BAS (open model) or continue and end into 126 the RADIUS server of an ISP (closed model). The PPPoE authentication 127 is done where the PPPoE tunnel ends. 129 2.2 Connections description (Unicast) 131 Here are the different steps of a connection to Internet : 133 - when an end user tries to go on the Internet, the satellite 134 terminal implements the LLTM : it initiates first a GRE tunnel 135 between its DVB interface and the LLTM server. Now a LAN has 136 been emulated and all the Ethernet frames can be directed to 137 the LLTM server and therefore to the BAS. 139 - the satellite terminal exchanges pieces of information with 140 the BAS (initiation session) in order to initiate the PPPoE 141 session. 143 - In case of cloded model the BAS redirect the PPP connection 144 to the right ISP through a L2TP tunnel. 146 - the end user can connect to a distant server of the Internet. 148 2.3 Multicast 150 It is important to notice that PPPoE supports only PPP connection for 151 Unicast flows. The multicast is provided directly by the ASP using IP 152 over LLTM. In this configuration, the ASP can offer n to m multicast 153 services. 154 There is also possibility to offer the Mbone connectity through the BAS 155 without using PPPoE. 157 3. Advantages 159 The Local Satellite Loop architecture offers the following advantages : 161 - a return channel flexibility : the use of LLTM allows to 162 define an access network wether with a satellite return channel 163 or with a terrestrial return channel. Besides a standby 164 terrestrial link can be used automatically in case of failure 165 of the satellite return channel. 167 - a multi-ISP configuration for the Internet access. 169 - a difference is made between the ASP and the ISP 171 - complementarity with the ADSL network : 172 * performances : more than 128 kbps for the return channel 173 and up to 40 Mbps for a gateway throughput 174 * client segmentation : corporate or residential 175 * interconnection with the terrestrial network 176 * reduction of the access costs 177 * re-use of the ADSL management system (accounting, 178 billing, etc.) 180 - interactif Multicast support (m to m) 182 4. Conclusion 184 The Local Satellite Loopb architecture has been already validated in laboratory. 185 A real experimentation will begin on the fourth quarter of 2001 with a few tens 186 of satellite terminals. Different evolutions are studied on multicast and security 187 aspects. 189 5. References 191 [UDLR] E. Duros, W. Dabbous, H. Izumiyama, N. Fujii, Y. Zhang, "A 192 Link-Layer Tunneling Mechanism for Unidirectional Links", RFC 3077, 193 March 2001 195 [PPPoE] L. Mamakos, K. Lidl, J. Evarts, D. Carrel, D. Simone, R. 196 Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", 197 RFC 2516, February 1999 199 [GRE] D. Farinacci, T. Li, S. Hanks, D. Meyer, P. Traina, "Generic 200 Routing Encapsulation (GRE)", RFC 2784, March 2000 202 6. Author's Addresses 204 Gilles Chanteau 205 France Telecom R&D 206 38/40 rue du G�n�ral Leclerc 207 92131 Issy-Les-Moulineaux Cedex 208 France 209 Phone: (+33) 1 45 29 58 67 210 EMail : gilles.chanteau@rd.francetelecom.com 212 Yann Codaccioni 213 France Telecom R&D 214 38/40 rue du G�n�ral Leclerc 215 92131 Issy-Les-Moulineaux Cedex 216 France 217 Phone: (+33) 1 45 29 64 67 218 EMail : yann.codaccioni@rd.francetelecom.com 220 Virginie Fain�ant 221 France Telecom R&D 222 38/40 rue du G�n�ral Leclerc 223 92131 Issy-Les-Moulineaux Cedex 224 France 225 Phone: (+33) 1 45 29 226 EMail : virginie.faineant@rd.francetelecom.com 228 7. Full copyright statement 230 Copyright (C) The Internet Society (1999). All Rights Reserved. 232 This document and translations of it may be copied and furnished to 233 others, and derivative works that comment on or otherwise explain it 234 or assist its implementation may be prepared, copied, published and 235 distributed, in whole or in part, without restriction of any kind, 236 provided that the above copyright notice and this paragraph are 237 included on all such copies and derivative works. 239 However, this document itself may not be modified in any way, such as 240 by removing the copyright notice or references to the Internet 241 Society or other Internet organizations, except as needed for the 242 purpose of developing Internet standards in which case the procedures 243 for copyrights defined in the Internet Standards process must be 244 followed, or as required to translate it into languages other than 245 English. 247 The limited permissions granted above are perpetual and will not be 248 revoked by the Internet Society or its successors or assigns. 250 This document and the information contained herein is provided on an 251 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 252 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 253 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 254 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 255 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.