This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
RIPE Action 21.9: Fwd: E-J B: Draft doc m.cast router in routing reg.
- Previous message (by thread): RIPE Action 21.9: proposal for an ext. of inet-rtr (Mbone R.)
- Next message (by thread): Hierarchical authorization proposal
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Wilfried Woeber, UniVie/ACOnet
woeber at cc.univie.ac.at
Thu Jan 25 19:21:02 CET 1996
FYI, this is the original proposal as circulated by Erik-Jan Bos. -Wilfried. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Subject: Draft document multicast router in routing registry From: Erik-Jan Bos <erik-jan.bos at surfnet.nl> Date: Sun, 07 May 1995 11:49:46 +0200 Mbone-EU, please find below a first version of a document describing a multicast router in a routing registry. I would like to have your comments and we can discuss it at the next Mbone WG meeting. I realize some of you might not have a chance to read it before the meeting. Well... here it is, I'll try to bring copies to the meeting. See you in Rome. --- Start of document A Multicast Router in the Routing Registry Erik-Jan Bos Document ID: ripe-nnn May, 1995 **** DRAFT ** WORK IN PROGRESS ** DRAFT **** ABSTRACT This document describes an addition to ripe-122 (Specifying an "Internet Router" in the Routing Registry) in which it is possible to define a multicast capable Internet routing within a routing registry. 1. Introduction With the growing of the Mbone worldwide, managing the Mbone becomes a complex task. The multicast-bone is starting to suffer from problems that used to be present in the unicast-bone several years ago, such as routing coordination. Today, registries are available for administering policies and routes and routers [1]. Tools are availble [2,3] for checking and analyzing the real world against what is registered. The Mbone could and should benefit from these technologies coming from the unicast world. The features of the specification described in this document will be usable e.g. in the RIPE Data Base, after review by the RIPE Data Base WG. After implementation tools could be developed for mapping and analyzing the Mbone. Furthermore, administrative details (such as contact person) are easily administered by well known procedures and easily retrievable. 2. Multicast routers versus unicast routers An "Internet Router" or a "gateway" in the current version of IP (IPv4) can be defined as follows [4]: "Gateways in the Internet form a cooperative, interconnected structure. Datagrams pass from gateway to gateway until they reach a gateway that can deliver the datagram directly." This definition can be applied to both unicast and multicast routers. Since both a unicast and multicast router are fulfilling the "Internet Router" function for different natures of traffic, there is no need for a special routing registry data base object. Moreover, both functions could be present in the same box. 3. Multicast router specification Since an Internet Router can perform both types of routing, this fact should be registerable in the routing registry. Each router is uniquely defined by by its object name, also known as the fully qualified domain name. Below is an example of a internet router object, specifying a multicast router: inet-rtr: broodjeham.surfnet.nl localas: AS1103 ifaddr: 192.87.106.102 255.255.255.0 ifaddr: 192.87.4.99 255.255.255.0 mpeer: 192.87.108.13 16 1 admin-c: Erik-Jan Bos tech-c: Henk Steenman notify: netmaster at surfnet.nl remarks: SURFnet Multicast router changed: Erik-Jan.Bos at surfnet.nl 950505 source: RIPE Several pieces of important information are present in this object. First of all there is the FQDN of the router, acting as object name. The Home Autonomous System Number is shown, which for a multicast router is merely for identification purposes only. Furthermore, the ifaddr:-lines show that this router has two interfaces, in two different networks. Finally, the DVMRP peers are shown with IP address, treshold and metric. All other attributes are common to other objects already defined for a routing registry [1]. For exact syntax definition see next chapter. 4. Multicast router Syntax Definition The multicast capable router object is defined here. Each of the possible attributes are shown, on a single line. The second column defined whether the attribute must be present [mandatory] of could be present [optional]. The third column defines whether exactly one line is allowed [single] or that more than one line of the same attribute is allowed [multiple]. In case an attribute has more lines than one, the name of the attribute must be repeated on each line. inet-rtr: [mandatory] [single] localas: [mandatory] [single] ifaddr: [mandatory] [multiple] mpeer: [mandatory] [multiple] admin-c: [mandatory] [multiple] tech-c: [mandatory] [multiple] notify: [optional] [multiple] remarks: [optional] [multiple] changed: [mandatory] [multiple] source: [mandatory] [single] Each attribute has the following syntax: inet-rtr: The fully qualified domain name of the router. localas: The Autonomous System to which the router belongs. ifaddr: An interface IPv4 address of the router. mpeer: A multicast peering of the router. Format: <mpeer address> <mpeer treshold> <mpeer metric> Example: mpeer: 192.87.108.13 16 1 Status: mandatory, multiple instances allowed. admin-c: Full name or uniquely assigned NIC-handle of a contact person for administrative matters. tech-c: Full name or uniquely assigned NIC-handle of a contact person for technical matters. notify: An e-mail address to which notifications of changes to this object should be send. remarks: Remarks or comments, for clarification purposes only. changed: The e-mail address and date of a change. source: Source of the information. 5. Acknowledgements This specification, being an addition to ripe-122, leans on the specification done by the author of ripe-122. Credits go to Tony Bates. Furthermore, the RIPE Mbone WG has done reviewing of this document and they receive credits as well. 6. Security considerations Security is not considered in this document. 7. References [1] Bates, Tony, "Specifying an Internet Router in the Routing Registry", ripe-122, October 1994. On-line at URL: ftp://ftp.ripe.net/ripe/docs/ripe-122.txt [2] PRIDE Tools Release 1. On-line at URL: ftp://ftp.ripe.net/pride/tools/pride-tools-1.tar.Z [3] Merit Inc. RRDB Tools. On-line at URL: ftp://rrdb.merit.edu/pub/meritrr [4] Douglas Comer, "Internetworking with TCP/IP", Prentice-Hall, 1988. ISBN: 0-13-470188-7. --- End of document __ Erik-Jan. --------------------------------------------------------------------------------
- Previous message (by thread): RIPE Action 21.9: proposal for an ext. of inet-rtr (Mbone R.)
- Next message (by thread): Hierarchical authorization proposal
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]