idnits 2.17.1 draft-ietf-ion-proxypar-arch-01.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 8 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (15 February 1999) is 9202 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'Dav97a' is mentioned on line 400, but not defined == Missing Reference: 'Dav97b' is mentioned on line 400, but not defined == Missing Reference: 'Dav97c' is mentioned on line 400, but not defined == Unused Reference: 'Dav99a' is defined on line 458, but no explicit reference was found in the text == Unused Reference: 'Dav99b' is defined on line 461, but no explicit reference was found in the text == Unused Reference: 'Dav99c' is defined on line 464, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'AF95' -- Possible downref: Non-RFC (?) normative reference: ref. 'AF96a' -- Possible downref: Non-RFC (?) normative reference: ref. 'AF96b' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ca96' -- Possible downref: Non-RFC (?) normative reference: ref. 'CH97' -- Possible downref: Non-RFC (?) normative reference: ref. 'Col97' -- Possible downref: Non-RFC (?) normative reference: ref. 'Dav99a' -- Possible downref: Non-RFC (?) normative reference: ref. 'Dav99b' -- Possible downref: Non-RFC (?) normative reference: ref. 'Dav99c' -- Possible downref: Non-RFC (?) normative reference: ref. 'DP97' ** Obsolete normative reference: RFC 1577 (ref. 'Lau94') (Obsoleted by RFC 2225) Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force P. Droz/T. Przygienda 2 INTERNET DRAFT IBM Corp./Bell Labs, Lucent 3 15 February 1999 5 Proxy PAR 6 8 Status of This Memo 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026. Internet Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its Areas, 12 and its Working Groups. Note that other groups may also distribute 13 working documents as Internet Drafts. 15 Internet Drafts are draft documents valid for a maximum of six 16 months. Internet Drafts may be updated, replaced, or obsoleted by 17 other documents at any time. It is not appropriate to use Internet 18 Drafts as reference material, or to cite them other than as a 19 ``working draft'' or ``work in progress.'' 20 Please check the I-D abstract listing contained in each Internet 21 Draft directory to learn the current status of this or any other 22 Internet Draft. 24 Abstract 25 Proxy PAR is a minimal version of PAR (PNNI Augmented Routing) that 26 gives ATM attached devices the ability to interact with PNNI devices 27 without the necessity to fully support PAR. Proxy PAR is designed as 28 a client/server interaction where the client side is much simpler 29 than the server side to allow fast implementation and deployment. 31 The purpose of Proxy PAR is to allow non-ATM devices to use the 32 flooding mechanisms provided by PNNI for registration and automatic 33 discovery of services offered by ATM attached devices. The first 34 version of PAR addresses mainly protocols available in IPv4. But 35 it also disposes of a generic interface to access the flooding of 36 PNNI. In addition, Proxy PAR capable servers provide filtering based 37 on VPN IDs, IP protocols and address prefixes. This enables for 38 instance routers in a certain VPN running OSPF to find OSPF neighbors 39 on the same subnet. The protocol is built using a registration/query 40 approach where devices can register their services and query for 41 services and protocols registered by other clients. 43 1. Introduction 45 In June 1996, the ATM Forum accepted the Proxy PAR contribution as 46 minimal subset of PAR, as a work item of the Routing and Addressing 47 (RA) working group which was previously called PNNI working 48 group [AF96b]. The PAR [Ca96] specification provides a detailed 49 description of the protocol including state machines and packet 50 formats. 51 The intention of this I-D is to provide general information about 52 Proxy PAR. For the detailed protocol description we refer the reader 53 to [Ca96]. 55 Proxy PAR is a protocol allowing for different ATM attached devices 56 (ATM and non-ATM devices) to interact with PAR capable switches 57 to exchange information about non-ATM services without executing 58 PAR themselves. The client side is much simpler in terms of 59 implementation complexity and memory requirements than a complete 60 PAR instance. This should allow an easy implementation on existing 61 IP device such as IP routers. Additionally, clients can use Proxy 62 PAR to register different non-ATM services and protocols they 63 support. The protocol has deliberately not been included as part of 64 ILMI [AF96a] due to the complexity of PAR information passed in the 65 protocol and the fact that it is intended for integration of non-ATM 66 protocols and services only. A device executing Proxy PAR does not 67 necessarily need to execute ILMI or UNI signalling although this 68 normally will be the case. 69 The protocol does not specify how a client should make use of the 70 obtained information to establish connectivity. For example, OSPF 71 routers finding themselves through Proxy PAR could establish a full 72 mesh of P2P VCs by means of RFC1577 [Lau94], or use RFC1793 [Moy95] 73 to interact with each other. For the same purpose LANE [AF95] or 74 MARS [Arm96] could be used. It is expected that the guidelines how 75 a certain protocol can make use of Proxy PAR should come out of the 76 appropriate working group or standardization body that is responsible 77 for the particular protocol. Currently, work in progress exists 78 to address the operation of OSPF in the context of ATM and Proxy 79 PAR [DP97]. Further work will address other protocols such as BGP-4. 81 The protocol has the ability to provide ATM address resolution for 82 IP attached devices, but such resolutions can also be achieved by 83 other protocols under specification in the IETF, e.g. [CH97, Col97]. 84 Again, the main purpose of the protocol is to allow the automatic 85 detection of devices over an ATM cloud in a distributed fashion, 86 omitting the usual pitfalls of server based solutions. Last but 87 not least, it should be mentioned here as well that the protocol 88 complements and coexists with the ongoing work in the IETF on server 89 detection via ILMI extensions [Dav97a, Dav97b, Dav97c]. 91 2. Proxy PAR Operation and Interaction with PNNI 92 The protocol is asymmetric and consists of a discovery and 93 query/registration part. The discovery is very similar to the 94 existing PNNI Hello protocol and is used to initiate and maintain 95 communication between adjacent clients and servers. The registration 96 and update part execute after a Proxy PAR adjacency has been 97 established. The client can register its own services by sending 98 registration messages to the server. The client obtains information 99 it is interested in by sending query messages to the server. When 100 the client needs to change it's set of registered protocols it has to 101 re-register with the server. The client can withdraw all registered 102 services by registering a null set of services. It is important 103 to note that the server side does not push new information to the 104 client, neither does the server keep any state describing which 105 information the client received. It is the responsibility of the 106 client to update and refresh its information and to discover new 107 clients or update its stored information about other clients by 108 issuing queries and registrations at appropriate time intervals. 109 This simplifies the protocol, but assumes that the client will not 110 store and request large amounts of data. The main responsibility of 111 the server is to flood the registered information through the PNNI 112 cloud such that potential clients can discover each other. The Proxy 113 PAR server side also provides filtering functions to support VPNs and 114 IP subnetting. It is assumed that services advertised by Proxy PAR 115 will be advertised by a relatively small number of clients and will 116 be fairly stable, so that polling and refreshing intervals can be 117 relatively long. 119 The Proxy PAR extensions rely on appropriate flooding of information 120 by the PNNI protocol. When the client side registers or re-registers 121 a new service through Proxy PAR, it associates an abstract membeship 122 scope with the service. The server side maps this membership scope 123 into a PNNI routing level that restricts the flooding. This allows 124 the changes of the PNNI routing level without reconfiguration of the 125 client. In addition, the server can setup the mapping table such 126 that a client can only flood information to a certain level. Nodes 127 within the PNNI network take into account the associated scope of the 128 information when it is flooded. It is thus possible to exploit the 129 PNNI routing hierarchy by announcing different protocols on different 131 +-+ 132 | | PNNI peer group # PPAR capable @ PNNI capable * Router 133 +-+ switch switch 135 Level 40 136 +---------------------------+ 137 | | 138 | | 139 | @ ---- @ ---- @ | 140 | | | | 141 +----- | ----------- | -----+ 142 | | 143 Level 60 | | 144 +------------- | ---+ +-- | --------------+ 145 | | | | | | 146 R1* ------#-P1------@ | | @---------P3-#------- * R3 147 | | | | | | 148 R2* ------#-P2------+ | | +---------P4-#------- * R4 149 | | | | 150 +-------------------+ +-------------------+ 152 Figure 1: OSPF and BGP scalability with Proxy PAR autodetection (ATM 153 Topology) 155 levels of the hierarchy e.g. OSPF could be run inside certain 156 peer-groups whereas BGP could be run between the set of peer-groups 157 running OSPF. Such an alignment or mapping of non-ATM protocols to 158 the PNNI hierarchy can drastically increase the scalability and 159 flexibility of Proxy PAR service. Figure 1 helps to visualize such a 160 scenario. For this topology following registrations are issued: 162 1. R1 registers OSPF protocol as running on the IP interface 1.1.1.1 163 and subnet 1.1.1/24 with scope 60 165 2. R2 registers OSPF protocol as running on the IP interface 1.1.1.2 166 and subnet 1.1.1/24 with scope 60 168 3. R3 registers OSPF protocol as running on the IP interface 1.1.2.1 169 and subnet 1.1.2/24 with scope 60 171 4. R4 registers OSPF protocol as running on the IP interface 1.1.2.2 172 and subnet 1.1.2/24 with scope 60 174 and 175 5. R1 registers BGP4 protocol as running on the IP interface 1.1.3.1 176 and subnet 1.1/16 with scope 40 within AS101 178 6. R3 registers BGP4 protocol as running on the IP interface 1.1.3.2 179 and subnet 1.1/16 with scope 40 within AS100 181 For simplicity the real PNNI routing level have been specified which 182 are 60 and 40. Instead of these two values the clients would use as 183 abstract membership scope "local" and "local+1". In addition, all 184 registered information would be part of the same VPN ID. 185 Table 1 describes the resulting distribution and visibility of 186 registrations and whether the routers not only see but also utilize 187 the received information. After convergence of protocols and 188 building of necessary adjacencies and sessions the overlying IP 189 topology is visualized in Figure 2. 191 Expressing the said above differently, one can say that if the scope 192 of the Proxy PAR information indicates that a distribution beyond 193 the boundaries of the peer group is necessary, the leader of a peer 195 AS101 DMZ AS100 196 ######### ########## 197 # # 198 | # | # | 199 +-- R1 ---------+ # R4 --+ 200 | # | # | 201 | # | BGP4 on # OSPF on | 202 | OSPF on # | subnet # subnet | 203 | subnet # | 1.1/16 # 1.1.2/24 | 204 | 1.1.1/24 # | # | 205 | # +------------------- R3 --+ 206 +-- R2 # | # | 207 | # # 208 ######### ########## 210 Figure 2: OSPF and BGP scalability with Proxy PAR autodetection (IP 211 Topology) 213 Reg# |1. |2. |3. |4. |5. |6. 214 ___Router#_|___|___|___|___|___|____ R registered 215 R1 |R |U | | |R |U Q seen through query 216 R2 |U |R | | |Q |Q U used (implies Q) 217 R3 | | |R |U |R |U 218 R4 | | |U |R |Q |Q 220 Table 1: Flooding Scopes of Proxy PAR Registrations 222 group collects such information and propagates it into a higher 223 layer of the PNNI hierarchy. As no assumptions except scope values 224 can normally be made about the information distributed (e.g. IP 225 addresses bound to AESAs are not assumed to be aligned with them in 226 any respect), such information cannot be summarised. This makes a 227 careful handling of scopes necessary to preserve the scalability of 228 the approach as described above. 230 3. Proxy PAR Protocols 232 3.1. The Hello Protocol 233 The Proxy PAR Hello Protocol is closely related to the Hello protocol 234 specified in [AF96b]. It uses the same packet header and version 235 negotiation methods. For the sake of simplicity, states that are 236 irrelevant to Proxy PAR have been removed from the original PNNI 237 Hello protocol. The purpose of the Proxy PAR Hello protocol is to 238 bring up and maintain a Proxy PAR adjacency between the client and 239 server that supports the exchange of registration and query messages. 240 If the protocol is executed across multiple, parallel links between 241 the same server and client pair, individual registration and 242 query sessions are associated with a specific link. It is the 243 responsibility of the client and server to assign registration and 244 query sessions to the different communication instances. Proxy PAR 245 can be run in the same granularity as ILMI [AF96a] to support virtual 246 links and VP tunnels. 248 In addition, to the PNNI Hello, the Proxy PAR Hellos travelling from 249 the server to the client inform the client about the lifetime the 250 server assigns to registered information. The client has to retrieve 251 this interval from the Hello packet and set its refresh interval to 252 a value below the obtained time interval in order to avoid the aging 253 out of registered information by the server. 255 3.2. Registration/Query Protocol 257 The registration and query protocols enable the client to 258 announce and learn about protocols supported by the clients. All 259 query/register operations are initiated by the clients. The server 260 never tries to push information to the client. It is the client's 261 responsibility to register and refresh the set of protocols supported 262 and re-register them when changes occur. In the same sense, the 263 client must query the information from the server at appropriate 264 time intervals if it wishes to obtain the latest information. It is 265 important to note that neither client nor server is supposed to cache 266 any state information about the information stored by the other side. 267 Registered information is associated with an ATM address and 268 scope inside the PNNI hierarchy. From the IP point of view, all 269 information is associated with a VPN ID, IP address, subnet mask, 270 and IP protocol family. In this context, each VPN refers to a 271 completely separated IP address space. For example describes an OSPF interface in VPN A. In 273 addition to the IP scope further parameters can be registered that 274 contain more detailed information about the protocol itself. In the 275 above example this would be OSPF specific information such as the 276 area ID or router priority. However, Proxy PAR server only takes 277 the ATM and IP specific information into account when retrieving 278 information that was queried for. Protocol specific information is 279 never looked at by a Proxy PAR server. 281 3.2.1. Registration Protocol 282 The registration protocol enables a client to register the protocols 283 and services it supports. All protocols are associated with a 284 specific AESA and membership scope in the PNNI hierarchy. As the 285 default scope, implementations should choose the local scope of the 286 PNNI peer group. In this way, manual configuration can be avoided 287 unless information has to cross PNNI peergroup boundaries. PNNI is 288 responsible for the correct flooding either in the local peer group 289 or across the hierarchy. 291 The registration protocol is aligned with the standard initial 292 topology database exchange protocol used in link-state routing 293 protocols as far as possible. It uses a window size of one. A 294 single information element is registered at a time and must be 295 acknowledged before a new registration packet can be sent. The 296 protocol uses 'initialization' and 'more' bits in the same manner 297 PNNI and OSPF do. Any registration on a link unconditionally 298 overwrites all registration data previously received on the same 299 link. By means of a return code the server indicates to the client 300 whether the registration was successful or not. 302 Apart form the IP related information the protocol also offers a 303 generic interface to the PNNI flooding. By means of so called System 304 Capabilities Information Groups other information can be distributed 305 that can be used for proprietary or experimental implementations. 307 3.2.2. Query Protocol 309 The client uses the query protocol to obtain information about 310 services registered by other clients. The client requests services 311 registered within a specific membership scope, VPN and IP address 312 prefix. It is always the client's task to request information, the 313 server never makes any attempt to push information to the client. 314 If the client needs to filter the returned data based on service 315 specific information, such as BGP AS, it must parse and interpret the 316 received information. The server never looks beyond the IP scope. 317 The more generic interface to the flooding is supported similar to 318 the registration protocol. 320 4. Supported Protocols 321 Currently the protocols indicated in Table 2 have been included. 322 Furthermore, for protocols marked with a 'yes' additional information 323 has been specified that is beneficial for their operation. Many of 324 the protocol do not need additional information, it is sufficient to 325 know that they are supported and to know to which addresses they are 326 bound. 328 In order to include other information in an experimental manner the 329 generic information element can be used to carry such information. 331 5. VPN Support 333 In order to implement virtual private networks all information 334 distributed via PAR can be scoped under a VPN ID. Based on this ID, 335 individual VPNs can be separated. Inside a certain VPN further 336 distinctions can be made according to IP address related information 337 and/or protocol type. 338 In most cases the best VPN support can be provided when Proxy PAR is 339 used between the client and server because in this way it is possible 340 to hide the real PNNI topology from the client. The PAR capable 341 Protocol | Additional Info 342 ______________|__________________ 344 OSPF | yes 345 RIP | 346 RIPv2 | 347 BGP3 | 348 BGP4 | yes 349 EGP | 350 IDPR | 351 MOSPF | yes 352 DVMRP | 353 CBT | 354 PIM-SM | 355 IGRP | 356 IS-IS | 357 ES-IS | 358 ICMP | 359 GGP | 360 BBN SPF IGP| 361 PIM-DM | 362 MARS | 363 NHRP | 364 ATMARP | 365 DHCP | 366 DNS | yes 368 Table 2: Additional Protocol Information Carried in PAR and PPAR 370 server performs the translation from the abstract membership scope 371 into the real PNNI routing level. In this way the real PNNI topology 372 is hidden from the client and the server can apply restrictions in 373 the PNNI scope. The server can for instance have a mapping such 374 that the membership scope "global" is mapped to the highest level 375 peergroup to which a particular VPN has access. Thus the membership 376 scopes can be seen as hierarchical structuring inside a certain VPN. 377 With such mappings a network provider can also change the mapping 378 having to reconfigure the clients. 379 For more secure VPN implementations it will also be necessary to 380 implement VPN ID filters on the server side. In this way a client 381 can be restricted to a certain set (typically one) of VPN IDs. The 382 server will then allow queries and registrations only from the 383 clients that are in the allowed VPNs. In this way it is possible to 384 avoid an attached client from finding devices that are outside of 385 its own VPN. There is even room for further restriction in terms of 386 not allowing wildcard queries by a client. In terms of security, 387 some of the protocols have their own security methods, so PAR is only 388 used for the discovery of the counterparts. For instance OSPF has 389 authentication which can be used during the OSPF operation. So even 390 in the case where two wrong partners find each other, they will not 391 communicate because they will not be able to authenticate each other. 393 The VPN ID used by PAR and Proxy PAR is aligned with the VPN ID used 394 by other protocols from the ATM Forum. The VPN ID is structured into 395 2 parts, namely the 3 bytes long OUI plus a 4 byte index. 397 6. Interoperation with ILMI based Server Discovery 399 PAR can be used to complement the server discovery via ILMI as 400 specified in [Dav97a, Dav97b, Dav97c]. It can be used to provide 401 the flooding of the information across the PNNI network. For this 402 purpose a server has to register with a PAR capable device. This can 403 be achieved via Proxy PAR or with a direct PAR interaction. Manual 404 configuration would also be possible. For instance the ATMARP server 405 could register its service via Proxy PAR. A direct interaction with 406 PAR will be required in order to provide an appropriate flooding 407 scope. 408 A PAR capable device that has the additional MIB variables in the 409 Service Registry MIB can set these variables when getting information 410 via PAR. All required information is either contained in PAR or 411 is static such as IP version. The ATM Forum is specifying the 412 mapping of the PAR information into the Service Registry MIB. This 413 specification will be pubished as an Appendix to the PAR document. 415 7. Security Consideration 416 The Proxy PAR protocol itself does not have its own security 417 concepts. As PAR is an extension to PNNI, it has all security 418 features that come with PNNI. In addition, the protocol is mainly 419 used for automatic discovery of peers for certain protocols. After 420 the discovery process the security concepts of the individual 421 protocol is used for the bring up. As explained in the section about 422 VPN support, the only security considerations are on the server side 423 where access filters for VPN IDs can be implemented and restrictive 424 membership scope mappings can be configured. 426 8. Conclusion 427 This I-D describes the basic functions of Proxy PAR that has been 428 specified within the ATM-Forum body. The main purpose of the 429 protocol is to provide automatic detection and configuration of 430 non-ATM devices over an ATM cloud. 432 In the future support for further protocols and address families may 433 be added to widen the scope of applicability of Proxy PAR. 435 References 437 [AF95] ATM-Forum. LAN Emulation over ATM 1.0. ATM Forum 438 af-lane-0021.000, January 1995. 440 [AF96a] ATM-Forum. Interim Local Management Interface (ILMI) 441 Specification 4.0. ATM Forum 95-0417R8, June 1996. 443 [AF96b] ATM-Forum. Private Network-Network Interface Specification 444 Version 1.0. ATM Forum af-pnni-0055.000, March 1996. 446 [Arm96] G. Armitage. Support for Multicast over UNI 3.0/3.1 based 447 ATM Networks, RFC 2022. Internet Engineering Task Force, 448 November 1996. 450 [Ca96] R. Callon and al. An Overview of PNNI Augmented Routing. 451 ATM Forum 96-0354, April 1996. 453 [CH97] R. Coltun and J. Heinanen. The OSPF Address Resolution 454 Advertisement Option. Internet Draft, 1997. 456 [Col97] R. Coltun. Opaque LSA in OSPF. Internet Draft, 1997. 458 [Dav99a] M. Davison. ILMI-Based Server Discovery for ATMARP. 459 Internet Draft, 1999. 461 [Dav99b] M. Davison. ILMI-Based Server Discovery for MARS. Internet 462 Draft, 1999. 464 [Dav99c] M. Davison. ILMI-Based Server Discovery for NHRP. Internet 465 Draft, 1999. 467 [DP97] P. Droz and T. Przygienda. OSPF over ATM and Proxy PAR. 468 Internet Draft, 1997. 470 [Lau94] M. Laubach. Classical IP and ARP over ATM, RFC 1577. 471 Internet Engineering Task Force, January 1994. 473 [Moy95] J. Moy. Extending OSPF to Support Demand Circuits, RFC 474 1793. Internet Engineering Task Force, April 1995. 476 Authors' Addresses 478 Tony Przygienda 479 Bell Labs, Lucent Technologies 480 101 Crawfords Corner Road 481 Holmdel, NJ 07733-3030 482 prz@dnrc.bell-labs.com 484 Patrick Droz 485 IBM Research Division 486 Zurich Research Laboratory 487 Saumerstrasse 4 488 8803 Ruschlikon 489 Switzerland 490 dro@zurich.ibm.com