idnits 2.17.1 draft-ietf-forces-netlink-02.txt: ** The Abstract section seems to be numbered 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 25 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 27 pages 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 21 instances of too long lines in the document, the longest one being 83 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 106 has weird spacing: '...Netlink layer...' == Line 367 has weird spacing: '...Netlink layer...' == Line 634 has weird spacing: '...sioning servi...' == Line 646 has weird spacing: '...th: the lengt...' == Line 654 has weird spacing: '...address scope...' == (10 more instances...) -- 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 (March 2002) is 8078 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-2119' is mentioned on line 39, but not defined == Unused Reference: 'RFC1633' is defined on line 1063, but no explicit reference was found in the text == Unused Reference: 'RFC1812' is defined on line 1067, but no explicit reference was found in the text == Unused Reference: 'RFC2475' is defined on line 1070, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1633 ** Downref: Normative reference to an Informational RFC: RFC 2475 ** Downref: Normative reference to an Historic RFC: RFC 1157 ** Obsolete normative reference: RFC 3036 (Obsoleted by RFC 5036) Summary: 13 errors (**), 0 flaws (~~), 13 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ForCES Working Group Jamal Hadi Salim 3 Internet Draft Znyx Networks 4 Hormuzd Khosravi 5 Intel 6 Andi Kleen 7 Suse 8 Alexey Kuznetsov 9 INR/Swsoft 10 March 2002 12 Netlink as an IP services protocol 13 draft-ietf-forces-netlink-02.txt 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as ``work in progress.'' 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Conventions used in this document 36 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 37 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 38 this document are to be interpreted as described in [RFC-2119]. 40 1. Abstract 42 This document describes Linux Netlink, which is used in Linux both 43 as an inter-kernel messaging system as well as between kernel and 45 jhs_hk_ak_ank draft-forces-netlink-02.txt 47 user-space. The purpose of this document is intended as informa- 48 tional in the context of prior art for the ForCES IETF working 49 group. The focus of this document is to describe netlink from a 50 context of a protocol between a Forwarding Engine Component (FEC) 51 and a Control Plane Component(CPC) that define an IP service. 53 The document ignores the ability of netlink as a inter-kernel mes- 54 saging system, as a an inter-process communication scheme (IPC) or 55 its use in configuring other non-network as well as network but 56 non-IP services (such as decnet etc). 58 2. Introduction 60 The concept of IP Service control-forwarding separation was first 61 introduced in the early 1980s by the BSD 4.4 routing sock- 62 ets[stevens]. The focus at that time was a simple IP(v4) forward- 63 ing service and how the CPC, either via a command line configura- 64 tion tool or a dynamic route daemon, can control forwarding tables 65 for that IPV4 forwarding service. 67 The IP world has evolved considerably since those days. Linux 68 netlink, when observed from a service provisioning point of view 69 takes routing sockets one step further by breaking the barrier of 70 focus around IPV4 forwarding. Since the linux 2.1 kernel, netlink 71 has been providing the IP service abstraction to a few services 72 other than the classical IPv4 forwarding. 74 We first give some concept definitions and then describe how 75 netlink fits in. 77 2.1. Some definitions 79 A Control plane(CP) is an execution environment that may have sev- 80 eral components which we refer to as CPCs. Each CPC provides con- 81 trol for a different IP service being executed by a FE component. 82 This means that there might be several CPCs on a physical CP if it 83 is controlling several IP services. In essence, the cohesion 84 between a CP component and a FE component is the service abstrac- 85 tion. 87 In the diagram below we show a simple FE<->CP setup to provide an 88 example of the classical IPv4 service with an extension to do some 89 basic QoS egress scheduling and how it fits in this described 91 jhs_hk_ak_ank draft-forces-netlink-02.txt 93 model. 95 Control Plane (CP) 96 .------------------------------------ 97 | /^^^^^\ /^^^^^\ | 98 | | | | COPS |-. | 99 | | ospfd | | PEP | | | 100 | | / \_____/ | | 101 /--------\_____/ | | | 102 | | | | | | 103 | |______________________|___|_________| 104 | | | | 105 ****************************************** 106 Forwarding ************* Netlink layer ************ 107 Engine (FE) ***************************************** 108 .-------------|-----------|------------|---|----------- 109 | IPv4 forwading | / | 110 | FE Service / / | 111 | Component / / | 112 | ---------------/---------------/--------- | 113 | | | / | | 114 packet | | --------|-- ----|----- | packet 115 in | | | IPV4 | | Egress | | out -->---> |------>|---->|Forwading |----->| QoS |--->| ---->|----> 116 | | | | | Scheduler| | | 117 | | ----------- ---------- | | 118 | | | | 119 | --------------------------------------- | 120 | | 121 ------------------------------------------------------- 123 2.1.1. Control Plane Components (CPCs) 125 Control plane components would encompass signalling protocols with 126 diversity ranging from dynamic routing protocols such as OSPF 127 [RFC2328] to tag distribution protocols such as CR-LDP [RFC3036]. 128 Classical Management protocols and activities also fall under this 129 category. These include SNMP [RFC1157], COPS [RFC2748] or propri- 130 etary CLI/GUI configuration mechanisms. 132 jhs_hk_ak_ank draft-forces-netlink-02.txt 134 The purpose of the control plane is to provide an execution envi- 135 ronment for the above mentioned activities with the ultimate goal 136 being to configure and manage the second NE component: the FE. The 137 result of the configuration would define the way packets travesing 138 the FE are treated. 140 In the above diagram, ospfd and COPS are distinct CPCs. 142 2.1.2. Forwarding Engine Components 144 The FE is the entity of the NE that incoming packets (from the net- 145 work into the NE) first encounter. 147 The FE's service specific component massages the packet to provide 148 it with a treatment to achieve a IP service as defined by the con- 149 trol plane components for that IP service. Different services will 150 utilize different FEC. Service modules maybe chained to achieve a 151 more complex service (as shown in the diagram). When built for 152 providing a specific service, the FE service component will adhere 153 to a Forwading Model. 155 In the above diagram, the IPV4 FE component includes both the IPV4 156 Forwarding service module as well as the Egress Scheduling service 157 module. Another service might may add a policy forwarder between 158 the IPV4 forwader and the QoS egress Scheduler. A simpler classi- 159 cal service would have constituted only the IPV4 forwarder. 161 2.1.3. IP Services 163 An IP Service is the treatment of an IP packet within the NE. This 164 treatment is provided by a combination of both the CPC and FEC 166 The time span of the service is from the moment when the packet 167 arrives at the NE to the moment it departs. In essence an IP ser- 168 vice in this context is a Per-Hop Behavior. A service control/sig- 169 naling protocol/management-application (CP components running on 170 NEs defining the end to end path) unifies the end to end view of 171 the IP service. As noted above, these CP components then define the 172 behavior of the FE (and therefore the NE) to a described packet. 174 A simple example of an IP service is the classical IPv4 Forwarding. 175 In this case, control components such as routing protocols(OSPF, 177 jhs_hk_ak_ank draft-forces-netlink-02.txt 179 RIP etc) and proprietary CLI/GUI configurations modify the FE's 180 forwarding tables in order to offer the simple service of forward- 181 ing packets to the next hop. Traditionally, NEs offering this sim- 182 ple service are known as routers. 184 Over the years it has become important to add aditional services to 185 the routers to meet emerging requirements. More complex services 186 extending classical forwarding were added and standardized. These 187 newer services might go beyond the layer 3 contents of the packet 188 header. However, the name "router", although a misnomer, is still 189 used to describe these NEs. Services (which may look beyond the 190 classical L3 headers) here include firewalling, Qos in Diffserv and 191 RSVP, NATs, policy based routing etc. Newer control protocols or 192 management activities are introduced with these new services. 194 One extreme definition of a IP service is something a service 195 provider would be able to charge for. 197 3. Netlink Architecture 199 IP services components control is defined by using templates. 201 The FEC and CPC participate to deliver the IP service by communi- 202 cating using these templates. The FEC might continously get 203 updates from the control plane component on how to operate the ser- 204 vice (example for V4 forwarding, route additions or deletions). 206 The interaction between the FEC and the CPC, in the netlink con- 207 text, would define a protocol. Netlink provides the mechanism for 208 the CPC (residing in user space) and FEC (residing in kernel space) 209 to have their own protocol definition. Kernel space and user space 210 just mean different protection domains. Therefore a wire protocol 211 is needed to communicate. The wire protocol would be normally be 212 provided by some privileged service that is able to copy between 213 multiple protection domains. We will refer to this service as the 214 netlink service. Netlink service could also be necapsulated to a 215 different transport layer if the CPC executes on a different node 216 than the FEC. The FEC and CPC, using netlink mechanisms, may 217 choose to define a reliable protocol between each other. By 218 default, however, netlink provides an unreliable communication. 220 Note that the FEC and CPC can both live in the same memory protec- 221 tion domain and use the connect() system call to create a path to 222 the peer and talk to each other. We will not discuss this further 223 other than to say it is available as a mechanism. Through out this 225 jhs_hk_ak_ank draft-forces-netlink-02.txt 227 document we will refer interchangebly to the FEC to mean kernel- 228 space and the CPC to mean user-space. This is not meant, however, 229 to restrict the two components to these protection domains or to 230 the same compute node. 232 Note: Netlink allows participation in IP services by both service 233 components. 235 3.1. Netlink Logical model 237 In the diagram below we show a simple FEC<->CPC logical relation- 238 ship. We use the example of IPV4 forwarding FEC (NETLINK_ROUTE, 239 which is discussed further below) as an example. 241 Control Plane (CP) 242 .------------------------------------ 243 | /^^^^^ /CPC-2 | 244 | | CPC-1 | | COPS | | 245 | | ospfd | | PEP | | 246 | / _____/ | 247 | _____/ | | 248 | | | | 249 ****************************************| 250 ************* BROADCAST WIRE ************ 251 FE---------- *****************************************. 252 | IPv4 forwading | | / | 253 | FEC | | | | 254 | --------------/-----|-----------|-------- | 255 | | / | | | | 256 | | .-------. .-------. .------. | | 257 | | |ingress| | IPV4 | |Egress| | | 258 | | |police | |Forward| | QoS | | | 259 | | |_______| |_______| |Sched | | | 260 | | ------ | | 261 | --------------------------------------- | 262 | | 263 ----------------------------------------------------- 265 Netlink logically models FECs and CPCs in the form of nodes inter- 266 connected to each other via a broadcast wire. 268 The wire is specific to a service. The example above shows the 269 broadcast wire belonging to the extended IPV4 forwarding service. 271 jhs_hk_ak_ank draft-forces-netlink-02.txt 273 Nodes connect to the wire and register to receive specific mes- 274 sages. CPCs may connect to multiple wires if it helps them to con- 275 trol the service better. All nodes(CPCs and FECs) dump packets on 276 the broadcast wire. Packets could be discarded by the wire if mal- 277 formed or not specifically formated for the wire. Dropped packets 278 are not seen by any of the nodes. The netlink service MAY signal 279 an error to the original if it detects an malformatted netlink 280 packet. 282 Packets sent on the wire could be broadcast, multicast or unicast. 283 FECs or CPCs register for and pick specific messages of interest 284 for processing or just monitoring purposes. 286 3.2. The message format 288 There are three levels to a netlink message: The general netlink 289 message header, the IP service specific template, the IP service 290 specific data. 292 0 1 2 3 293 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | | 296 | Netlink message header | 297 | | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | | 300 | IP Service Template | 301 | | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | | 304 | IP Service specific data in TLVs | 305 | | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 The netlink message is used to communicate between the FEC and CPC 309 for parametrization of the FECs, asynchoronous event notification 310 of FEC events to the CPCs and statistics querying/gathering (typi- 311 cally by the CPC). The Netlink message header is generic for all 312 services whereas the IP Service Template header is specific to a 313 service. Each IP Service then carries parameterization 314 data(CPC->FEC direction) or response (FEC->CPC direction). These 315 are in TLV format and unique just to the service. 317 jhs_hk_ak_ank draft-forces-netlink-02.txt 319 3.3. Protocol Model 321 This section expands on how netlink provides the mechanism for ser- 322 vice oriented FEC and CPC interaction. 324 3.3.1. Service Addressing 326 Access is provided by first connecting to the service on the FE. 327 This is done by making a socket() system call to the PF_NETLINK 328 domain. Each FEC is identified by a protocol number. One may open 329 either SOCK_RAW or SOCK_DGRAM type sockets although netlink doesnt 330 distinguish the two. The socket connection provides the basis for 331 the FE<->CP addressing. 333 Connecting to a service is followed (at any point during the life 334 of the connection) by issuing either a service specific command 335 mostly for configuration purposes (from the CPC to the FEC) or sub- 336 scribing/unsubscribing to service(s') events, or statistics collec- 337 tion. 339 3.3.1.1. Sample Service Hierachy 341 In the diagram below we show a simple IP service, foo, and the 342 interaction it has between CP and FE components for the ser- 343 vice(labels 1-3). 345 We introduce the diagram below to demonstrate CP<->FE addressing. 346 In this section we illustrate only the addressing semantics. In 347 section 4, the diagram is referenced again to define the protocol 348 interaction between service foo's CPC and FEC (labels 4-10). 350 jhs_hk_ak_ank draft-forces-netlink-02.txt 352 CP 353 [--------------------------------------------------------. 354 | .-----. | 355 | | . -------. | 356 | | CLI | / | 357 | | | | CP protocol | 358 | /->> -. | component | <-. | 359 | __ _/ | | For | | | 360 | | | IP service | ^ | 361 | Y | foo | | | 362 | | ___________/ ^ | 363 | Y 1,4,6,8,9 / ^ 2,5,10 | 3,7 | 364 --------------- Y------------/---|----------|----------- 365 | ^ | ^ 366 **|***********|****|**********|********** 367 ************* Netlink layer ************ 368 **|***********|****|**********|********** 369 FE | | ^ ^ 370 .-------- Y-----------Y----|--------- |----. 371 | | / | 372 | Y / | 373 | . --------^-------. / | 374 | |FE component/module|/ | 375 | | for IP Service | | 376 --->---|------>---| foo |----->-----|------>-- 377 | ------------------- | 378 | | 379 | | 380 ------------------------------------------ 382 The control plane protocol for IP service foo does the following to 383 connect to its FE counterpart. The steps below are also numbered 384 above in the diagram. 386 1) Connect to IP service foo through a socket connect. A typical con- 387 nection would be via a call to: socket(AF_NETLINK, SOCK_RAW, 388 NETLINK_FOO) 390 2) Bind to listen to specific async events for service foo 392 3) Bind to listen to specific async FE events 394 jhs_hk_ak_ank draft-forces-netlink-02.txt 396 3.3.2. Netlink message header 398 Netlink messages consist of a byte stream with one or multiple 399 Netlink headers and associated payload. If the payload is too big 400 to fit into a single message it can be split over multiple netlink 401 messages. This is called a multipart message. For multipart mes- 402 sages the first and all following headers have the NLM_F_MULTI 403 netlink header flag set, except for the last header which has the 404 netlink header type NLMSG_DONE. 406 The netlink message header is shown below. 408 0 1 2 3 409 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 410 0 1 2 3 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Length | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Type | Flags | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Sequence Number | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Process PID | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 The fields in the header are: 423 jhs_hk_ak_ank draft-forces-netlink-02.txt 425 Length: 32 bits 426 The length of the message in bytes including the header. 428 Type: 16 bits 429 This field describes the message content. 430 It can be one of the standard message types: 431 NLMSG_NOOP message is ignored 432 NLMSG_ERROR the message signals an error and the payload 433 contains a nlmsgerr structure. This can be looked 434 at as a NACK and typically it is from FEC to CPC. 435 NLMSG_DONE message terminates a multipart message 437 Individual IP Services specify more message types, for e.g., 438 NETLINK_ROUTE Service specifies several types such as RTM_NEWLINK, 439 RTM_DELLINK, RTM_GETLINK, RTM_NEWADDR, RTM_DELADDR, RTM_NEWROUTE, 440 RTM_DELROUTE, etc. 442 Flags: 16 bits 443 The standard flag bits used in netlink are 444 NLM_F_REQUEST Must be set on all request messages (typically 445 from user space to kernel space) 446 NLM_F_MULTI Indicates the message is part of a multipart 447 message terminated by NLMSG_DONE 448 NLM_F_ACK Request for an acknowledgment on success. 449 Typical direction of request is from user 450 space to kernel space. 451 NLM_F_ECHO Echo this request. Typical direction of 452 request is from user space to kernel space. 454 Additional flag bits for GET requests on config information in 455 the FEC. 456 NLM_F_ROOT Return the complete table instead of a 457 single entry. 458 NLM_F_MATCH Return all matching criteria passed in 459 message content 460 NLM_F_ATOMIC Return an atomic snapshot of the table being 461 referenced. This may require special privileges 462 because it has the potential to interrupt 463 service in the FE for a longer time. 465 Convenience macros for flag bits: 466 NLM_F_DUMP This is NLM_F_ROOT or'ed with NLM_F_MATCH 468 Additional flag bits for NEW requests 469 NLM_F_REPLACE Replace existing matching config object with 470 this request. 471 NLM_F_EXCL Don't replace the config object if it already 472 exists. 474 jhs_hk_ak_ank draft-forces-netlink-02.txt 476 NLM_F_CREATE Create config object if it doesn't already 477 exist. 478 NLM_F_APPEND Add to the end of the object list. 480 For those familiar with BSDish use of such operations in route 481 sockets, the equivalent translations are: 483 - BSD ADD operation equates to NLM_F_CREATE or-ed 484 with NLM_F_EXCL 485 - BSD CHANGE operation equates to NLM_F_REPLACE 486 - BSD Check operation equates to NLM_F_EXCL 487 - BSD APPEND equivalent is actually mapped to 488 NLM_F_CREATE 490 Sequence Number: 32 bits 491 The sequence number of the message. 493 Process PID: 32 bits 494 The PID of the process sending the message. The PID is used by the 495 kernel to multiplex to the correct sockets. A PID of zero is used 496 when sending messages to user space from the kernel. netlink service 497 fills in an appropiate value when zero. 499 3.3.2.1. Mechanisms for creating protocols 501 One could create a reliable protocol between an FEC and a CPC by 502 using the combination of sequence numbers, ACKs and retransmit 503 timers. Both sequence numbers and ACKs are provided by netlink. 504 Timers are provided by Linux. 506 One could create a heartbeat protocol between the FEC and CPC by 507 using the ECHO flags and the NLMSG_NOOP message. 509 3.3.2.2. The ACK netlink message 511 This message is actually used to denote both an ACK and a NACK. 512 Typically the direction is from kernel to user space (in response 513 to an ACK request message). However, user space should be able to 514 send ACKs back to kernel space when requested. This is IP service 515 specific. 517 jhs_hk_ak_ank draft-forces-netlink-02.txt 519 0 1 2 3 520 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 521 0 1 2 3 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | Netlink message header | 524 | type = NLMSG_ERROR | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | error code | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | OLD Netlink message header | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 Error code: integer (typically 32 bits) 533 Error code of zero indicates that the message is an ACK response. 534 An ACK response message contains the original netlink message 535 header that can be used to compare against (sent sequence numbers 536 etc). 538 A non-zero error message is equivalent to a Negative ACK (NACK). 539 In such a situation, the netlink data that was sent down to the 540 kernel is returned appended to the original netlink message header. 541 An error code printable via the perror() is also set (not in the 542 message header, rather in the executing environment state vari- 543 able). 545 3.3.3. FE System services' templates 547 These are services that are offered by the system for general use 548 by other services. They include ability to configure, gather 549 statistics and listen to changes in shared resources. IP address 550 management, link events etc fit here. We separate them into this 551 section here for logical purposes despite the fact that they are 552 accessed via the NETLINK_ROUTE FEC. The reason that they exist 553 within NETLINK_ROUTE is due to historical cruft based on the fact 554 that BSD 4.4 rather narrowly focussed Route Sockets implemented 555 them as part of the IPV4 forwarding sockets. 557 3.3.3.1. 559 Network Interface Service Module 561 jhs_hk_ak_ank draft-forces-netlink-02.txt 563 This service provides the ability to create, remove or get informa- 564 tion about a specific network interface. The network interface 565 could be either physical or virtual and is network protocol inde- 566 pendent (example an x.25 interface can be defined via this mes- 567 sage). The Interface service message template is shown below. 569 0 1 2 3 570 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 571 0 1 2 3 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | Family | Padding | Device Type | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | Interface Index | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | Device Flags | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | Change Mask | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 Family: This is always set to AF_UNSPEC 584 Device Type: This defines the type of the link. The link could be 585 ethernet, a tunnel etc. Although we are interested only in IPV4, 586 the link type is protocol independent. 588 Interface Index: uniquely identifies interface. 590 Device Flags: 592 IFF_UP Interface is running. 593 IFF_BROADCAST Valid broadcast address set. 594 IFF_DEBUG Internal debugging flag. 595 IFF_LOOPBACK Interface is a loopback interface. 596 IFF_POINTOPOINT Interface is a point-to-point link. 597 IFF_RUNNING Resources allocated. 598 IFF_NOARP No arp protocol 599 IFF_PROMISC Interface is in promiscuous mode. 600 IFF_NOTRAILERS Avoid use of trailers. 601 IFF_ALLMULTI Receive all multicast packets. 602 IFF_MASTER Master of a load balancing bundle. 603 IFF_SLAVE Slave of a load balancing bundle. 604 IFF_MULTICAST Supports multicast 605 IFF_PORTSEL Is able to select media type via ifmap. 606 IFF_AUTOMEDIA Auto media selection active. 607 IFF_DYNAMIC Interface Address is not permanent. 609 jhs_hk_ak_ank draft-forces-netlink-02.txt 611 Change Mask: Reserved for future use. Must be set to 0xFFFFFFFF. 613 Applicable attributes: 614 attribute description 615 ....................................................... 616 IFLA_UNSPEC - unspecified. 617 IFLA_ADDRESS hardware address interface L2 address 618 IFLA_BROADCAST hardware address L2 broadcast 619 address. 620 IFLA_IFNAME ascii string device name. 621 IFLA_MTU MTU of the device. 622 IFLA_LINK Link type. 623 IFLA_QDISC ascii string defining Queueing 624 discipline. 625 IFLA_STATS Interface Statistics. 627 Netlink message types specific to this service: RTM_NEWLINK, 628 RTM_DELLINK, RTM_GETLINK 630 3.3.3.2. IP Address Service module 632 This service provides the ability to add, remove or receive information 633 about an IP address associated with an interface. The Address provi- 634 sioning service message template is shown below. 636 0 1 2 3 637 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 638 0 1 2 3 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | Family | Length | Flags | Scope | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | Interface Index | 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 Family: AF_INET for IPV4 or AF_INET6 for IPV6. 646 Length: the length of the address mask 647 Flags: IFA_F_SECONDARY for secondary address (alias interface), 648 IFA_F_PERMANENT for a permanent address set by the user as 649 opposed to dynamic addresses. 650 other flags include: 651 IFA_F_DEPRECATED which defines deprecated (IPV6) address 652 IFA_F_TENTATIVE which defines tentative (IPV6) address 654 Scope: the address scope 656 jhs_hk_ak_ank draft-forces-netlink-02.txt 658 Applicable attributes: 659 attribute description 660 ....................................................... 661 IFA_UNSPEC - unspecified. 662 IFA_ADDRESS raw protocol address of interface 663 IFA_LOCAL raw protocol local address 664 IFA_LABEL ascii string name of the interface 665 reffered to. 666 IFA_BROADCAST raw protocol broadcast address. 667 IFA_ANYCAST raw protocol anycast address 668 IFA_CACHEINFO cacheinfo address information. 670 Define cacheinfo here -- JHS 672 netlink messages specific to this service: RTM_NEWADDR, 673 RTM_DELADDR, RTM_GETADDR 675 4. Sample Protocol for The foo IP service 677 Our proverbial IP service "foo" is used again to demonstrate how 678 one can deploy a simple IP service control using netlink. 680 These steps are continued from the "Sample Service Hierachy" sec- 681 tion. 683 4) query for current config of FE component 685 5) receive response to 4) via channel on 3) 687 6) query for current state of IP service foo 689 7) receive response to 6) via channel on 2) 691 9) register the protocol specific packets you would like the FE to 692 forward to you 694 10) send specific service foo commands and receive responses for them 695 if needed 697 4.1. Interacting with other IP services 699 jhs_hk_ak_ank draft-forces-netlink-02.txt 701 The last diagram shows another control component configuring the 702 same service. In this case, it is a proprietary Command Line Inter- 703 face. The CLI (may or ) may not be using the netlink protocol to 704 communicate to the foo component. If the CLI should issue commands 705 that will affect the policy of the FEC for service "foo" then, then 706 the "foo" CPC is notified. It could then make algorithmic decisions 707 based on this input (example if a policy that foo installed was 708 deleted, there might be need to propagate this to all the peers of 709 service "foo"). 711 5. Currently Defined netlink IP services 713 Although there are many other IP services defined which are using 714 netlink, we will only mention those integrated into the kernel 715 today (kernel version 2.4.6). These are: 717 NETLINK_ROUTE,NETLINK_FIREWALL,NETLINK_ARPD,NETLINK_ROUTE6, 718 NETLINK_IP6_FW 720 5.1. IP Service NETLINK_ROUTE 722 This service allows CPCs to modify the IPv4 routing table in the 723 Forwarding Engine. It can also be used by CPCs to receive routing 724 updates as well as collecting statistics. 726 5.1.1. Network Route Service Module 728 This service provides the ability to create, remove or receive informa- 729 tion about a network route. The service message template is shown 730 below. 732 jhs_hk_ak_ank draft-forces-netlink-02.txt 734 0 1 2 3 735 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 736 0 1 2 3 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | Family | Src length | Dest length | TOS | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | Table ID | Protocol | Scope | Type | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | Flags | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 Family: Address family of route. AF_INET for IPV4 and AF_INET6 for 746 IPV6. 748 Src length: prefix length of source 750 Dest length: Prefix length of destination IP address 752 TOS: the 8 bit tos (should be deprecated to make room for DSCP) 754 Table ID: Table identifier. Upto 255 route tables are supported. 755 RT_TABLE_UNSPEC an unspecified routing table 756 RT_TABLE_DEFAULT the default table 757 RT_TABLE_MAIN the main table 758 RT_TABLE_LOCAL the local table 760 The user may assign arbitary values between 761 RT_TABLE_UNSPEC and RT_TABLE_DEFAULT. 763 Protocol: identifies what/who added the route. Described further 764 below. 765 protocol Route origin. 766 .............................................. 767 RTPROT_UNSPEC unknown 768 RTPROT_REDIRECT by an ICMP redirect 769 (currently unused) 770 RTPROT_KERNEL by the kernel 771 RTPROT_BOOT during boot 772 RTPROT_STATIC by the administrator 774 Values larger than RTPROT_STATIC are not interpreted by the ker- 775 nel, they are just for user information. They may be used to tag 776 the source of a routing information or to distingush between multiple 777 routing daemons. See for the routing daemon 778 identifiers which are already assigned. 780 jhs_hk_ak_ank draft-forces-netlink-02.txt 782 Scope: Route scope (distance to destination). 783 RT_SCOPE_UNIVERSE global route 784 RT_SCOPE_SITE interior route in the 785 local autonomous system 786 RT_SCOPE_LINK route on this link 787 RT_SCOPE_HOST route on the local host 788 RT_SCOPE_NOWHERE destination doesn't exist 790 The values between RT_SCOPE_UNIVERSE and RT_SCOPE_SITE are avail- 791 able to the user. 793 Type: The type of route. 795 Route type description 796 ------------------------------------------------- 797 RTN_UNSPEC unknown route 798 RTN_UNICAST a gateway or direct route 799 RTN_LOCAL a local interface route 800 RTN_BROADCAST a local broadcast route 801 (sent as a broadcast) 802 RTN_ANYCAST a local broadcast route 803 (sent as a unicast) 804 RTN_MULTICAST a multicast route 805 RTN_BLACKHOLE a packet dropping route 806 RTN_UNREACHABLE an unreachable destination 807 RTN_PROHIBIT a packet rejection route 808 RTN_THROW continue routing lookup in another 809 table 810 RTN_NAT a network address translation rule 811 RTN_XRESOLVE refer to an external resolver (not 812 implemented) 814 Flags: further qualify the route. 815 RTM_F_NOTIFY if the route changes, notify the 816 user via rtnetlink 817 RTM_F_CLONED route is cloned from another route 818 RTM_F_EQUALIZE a multicast equalizer (not yet 819 implemented) 821 Attributes applicable to this service: 823 jhs_hk_ak_ank draft-forces-netlink-02.txt 825 Attribute description 826 ----------------------------------------------- 827 RTA_UNSPEC ignored. 828 RTA_DST protocol address for route 829 destination address. 830 RTA_SRC protocol address for route source 831 address. 832 RTA_IIF Input interface index. 833 RTA_OIF Output interface index. 834 RTA_GATEWAY protocol address for the gateway of 835 the route 836 RTA_PRIORITY Priority of route. 837 RTA_PREFSRC 838 RTA_METRICS Route metric 839 RTA_MULTIPATH 840 RTA_PROTOINFO 841 RTA_FLOW 842 RTA_CACHEINFO 844 additional netlink message types applicable to this service: 845 RTM_NEWROUTE, RTM_DELROUTE, RTM_GETROUTE 847 5.1.2. Neighbour Setup Service Module 849 This service provides the ability to add, remove or receive infor- 850 mation about a neighbour table entry (e.g. an ARP entry). The ser- 851 vice message template is shown below. 853 0 1 2 3 854 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 855 0 1 2 3 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 | Family | Padding | Padding | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | Interface Index | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | State | Flags | Type | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 jhs_hk_ak_ank draft-forces-netlink-02.txt 866 Family: Address Family 868 Interface Index: The unique interface index 870 State: is a bitmask of the following states: 871 NUD_INCOMPLETE a currently resolving cache entry 872 NUD_REACHABLE a confirmed working cache entry 873 NUD_STALE an expired cache entry 874 NUD_DELAY an entry waiting for a timer 875 NUD_PROBE a cache entry that is currently 876 reprobed 877 NUD_FAILED an invalid cache entry 878 NUD_NOARP a device with no destination cache 879 NUD_PERMANENT a static entry 881 Flags: one of: 882 NTF_PROXY a proxy arp entry 883 NTF_ROUTER an IPv6 router 885 Attributes applicable to this service: 886 Attributes description 887 ------------------------------------ 888 NDA_UNSPEC unknown type 889 NDA_DST a neighbour cache network 890 layer destination address 891 NDA_LLADDR a neighbour cache link layer 892 address 893 NDA_CACHEINFO cache statistics. 895 Describe the NDA_CACHEINFO nda_cacheinfo header later --JHS 897 additional netlink message types applicable to this service: 898 RTM_NEWNEIGH, RTM_DELNEIGH, RTM_GETNEIGH 900 5.1.3. Traffic Control Service 902 This service provides the ability to provision, query or listen to 903 events under the auspicies of traffic control. These include Queueing 904 disciplines (schedulers and queue treatment algorithms eg Priority based 905 scheduler or RED algorithm) and classifiers. Linux Traffic Control Ser- 906 vice is very flexible and allows for hierachical cascading of the dif- 907 ferent blocks for traffic sharing. The service message template which 908 makes this possible is shown below. Each of the specific component of 909 the model has unique attributes which describe it best. The common 911 jhs_hk_ak_ank draft-forces-netlink-02.txt 913 attributes as well which are described below. 915 0 1 2 3 916 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 917 0 1 2 3 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 | Family | Padding | Padding | 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 | Interface Index | 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 | Qdisc handle | 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 | Parent Qdisc | 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 | TCM Info | 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 jhs_hk_ak_ank draft-forces-netlink-02.txt 932 Family: Address Family 934 Interface Index: The unique interface index 936 Qdisc handle: unique identifier for instance of queueing discipline. 937 Typically this is split into major:minor of 16 bits each. The major 938 number would also be the major number of the parent of this instance. 940 Parent Qdisc: This is used in hierarchical layering of queueing 941 disciplines. 942 If this value and the Qdisc handle are the same and equal to TC_H_ROOT 943 then the defined qdisc is the top most layer known as the root qdisc. 945 TCM Info: This is set by the FE to 1 typically except when the qdisc 946 instance is in use, in which case it is set to imply a reference count. 948 Attributes applicable to this service: 950 Attribute description 951 ------------------------------------ 952 TCA_KIND canonical name of FE component 953 TCA_STATS generic usage statistics of FEC 954 TCA_RATE rate estimator being attached to 955 FEC. Takes snapshots of stats to 956 compute rate 957 TCA_XSTATS specific statistics of FEC 958 TCA_OPTIONS nested FEC-specific attributes 960 [should we define all FEC-specific attributes? Seems like a lot of work 961 -- jhs] 963 [We still need to talk about classes and filters; later -- jhs] 965 5.2. IP Service NETLINK_FIREWALL 967 This service allows CPCs to receive packets sent by the IPv4 fire- 968 wall service in the FE. 970 Two types of messages exist that can be sent from CPC to FEC. These 971 are: Mode messages and Verdict messages. The formats are described 972 below. 974 jhs_hk_ak_ank draft-forces-netlink-02.txt 976 The Verdict message format is as follows 978 0 1 2 3 979 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 980 0 1 2 3 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 | Value | 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | Packet ID | 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 | Data Length | 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 | Payload ... | 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 A ipq_packet_msg packet type is sent from the FEC to the CPC. The 992 format is described below ==> We need to complete this later 994 5.3. IP Service NETLINK_ARPD 996 This service is used by CPCs for managing the ARP table in FE. 998 5.4. IP Service NETLINK_ROUTE6 1000 This service allows CPCs to modify the IPv6 routing table in the 1001 FE. It can also be used by CPCs to receive routing updates. 1003 jhs_hk_ak_ank draft-forces-netlink-02.txt 1005 0 1 2 3 1006 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1007 0 1 2 3 1008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1009 | IPv6 dst addr | 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 | IPv6 dst addr | 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 | IPv6 dst addr | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 | IPv6 dst addr | 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 | IPv6 src addr | 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 | IPv6 src addr | 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 | IPv6 src addr | 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 | IPv6 src addr | 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1025 | IPv6 gw addr | 1026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1027 | IPv6 gw addr | 1028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1029 | IPv6 gw addr | 1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1031 | IPv6 gw addr | 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1033 | Type | 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1035 | dst length | src length | 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 | Metric | 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 | Info | 1040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1041 | Flags | 1042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1043 | Interface Index | 1044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1046 5.5. IP Service NETLINK_IP6_FW 1048 This service allows CPCs to receive packets that failed the IPv6 1050 jhs_hk_ak_ank draft-forces-netlink-02.txt 1052 firewall checks by that module in the FE. 1054 6. Security Considerations 1056 Netlink lives in a trusted environment of a single host separated 1057 by kernel and user space. Linux capabilities ensures that only 1058 someone with CAP_NET_ADMIN capability (typically root user) is 1059 allowed to open sockets. 1061 7. References 1063 [RFC1633] R. Braden, D. Clark, and S. Shenker, "Integrated 1064 Services in the Internet Architecture: an Overview", RFC 1633, 1065 ISI, MIT, and PARC, June 1994. 1067 [RFC1812] F. Baker, "Requirements for IP Version 4 1068 Routers", RFC 1812, June 1995. 1070 [RFC2475] M. Carlson, W. Weiss, S. Blake, Z. Wang, D. 1071 Black, and E. Davies, "An Architecture for Differentiated 1072 Services", RFC 2475, December 1998. 1074 [RFC2748] J. Boyle, R. Cohen, D. Durham, S. Herzog, R. 1075 Rajan, A. Sastry, "The COPS (Common Open Policy Service) Pro- 1076 tocol", RFC 2748, January 2000. 1078 [RFC2328] J. Moy, "OSPF Version 2", RFC 2328, April 1998. 1080 [RFC1157] J.D. Case, M. Fedor, M.L. Schoffstall, C. Davin, 1081 "Simple Network Management Protocol (SNMP)", RFC 1157, May 1082 1990. 1084 [RFC3036] L. Andersson, P. Doolan, N. Feldman, A. Fredette, 1085 B. Thomas "LDP Specification", RFC 3036, January 2001. 1087 jhs_hk_ak_ank draft-forces-netlink-02.txt 1089 [stevens] G.R Wright, W. Richard Stevens. "TCP/IP Illus- 1090 trated Volume 2, Chapter 20", June 1995 1092 8. Acknowledgements 1094 1) Andi Kleen for man pages on netlink and rtnetlink. 1096 2) Alexey Kuznetsov is credited for extending netlink to the IP ser- 1097 vice delivery model. The original netlink character device was 1098 written by Alan Cox. 1100 9. Author's Address: 1102 Jamal Hadi Salim 1103 Znyx Networks 1104 Ottawa, Ontario 1105 Canada 1106 hadi@znyx.com 1108 Hormuzd M Khosravi 1109 Intel 1110 2111 N.E. 25th Avenue JF3-206 1111 Hillsboro OR 97124-5961 1112 USA 1113 1 503 264 0334 1114 hormuzd.m.khosravi@intel.com 1116 Andi Kleen 1117 SuSE 1118 Stahlgruberring 28 1119 81829 Muenchen 1120 Germany 1122 Alexey Kuznetsov 1123 INR/Swsoft 1124 Moscow 1125 Russia