rfc-editor@rfc-editor.org: RFC 3549 on Linux Netlink as an IP Services Protocol

rfc-editor@rfc-editor.org: RFC 3549 on Linux Netlink as an IP Services Protocol

[Michael Richardson]

>From owner-ietf-announce@ietf.org  Wed Jul  2 21:00:43 2003
Return-Path: <owner-ietf-announce@ietf.org>
Message-Id: <200307022318.h62NI9L04528@gamma.isi.edu>
To: IETF-Announce: ;
Subject: RFC 3549 on Linux Netlink as an IP Services Protocol
Cc: rfc-editor@rfc-editor.org, forces@peach.ease.lsoft.com
From: rfc-editor@rfc-editor.org
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 02 Jul 2003 16:18:09 -0700
Sender: owner-ietf-announce@ietf.org
Precedence: bulk


--NextPart


A new Request for Comments is now available in online RFC libraries.


        RFC 3549

        Title:      Linux Netlink as an IP Services Protocol
        Author(s):  J. Salim, H. Khosravi, A. Kleen, A. Kuznetsov
        Status:     Informational
        Date:       July 2003
        Mailbox:    hadi@znyx.com, hormuzd.m.khosravi@intel.com,
                    ak@suse.de, kuznet@ms2.inr.ac.ru
        Pages:      33
        Characters: 72161
        Updates/Obsoletes/SeeAlso:  None

        I-D Tag:    draft-ietf-forces-netlink-04.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3549.txt


This document describes Linux Netlink, which is used in Linux both
as an intra-kernel messaging system as well as between kernel and
user space.  The focus of this document is to describe Netlink's
functionality as a protocol between a Forwarding Engine Component
(FEC) and a Control Plane Component (CPC), the two components that
define an IP service.  As a result of this focus, this document
ignores other uses of Netlink, including its use as a intra-kernel
messaging system, as an inter-process communication scheme (IPC), or
as a configuration tool for other non-networking or non-IP network
services (such as decnet, etc.).

This document is intended as informational in the context of prior art
for the ForCES IETF working group.

This document is a product of the Forwarding and Control Element
Separation Working Group of the IETF.

This memo provides information for the Internet community.  It does
not specify an Internet standard of any kind.  Distribution of this
memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 
help: ways_to_get_rfcs.  For example:

        To: rfc-info@RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="RFC-INFO@RFC-EDITOR.ORG"

Content-Type: text/plain
Content-ID: <030702161638.RFC@RFC-EDITOR.ORG>

RETRIEVE: rfc
DOC-ID: rfc3549

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc3549.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

Content-Type: text/plain
Content-ID: <030702161638.RFC@RFC-EDITOR.ORG>

--OtherAccess--
--NextPart--

Re: rfc-editor@rfc-editor.org: RFC 3549 on Linux Netlink as an IP Services Protocol

[Ben Greear]

Please make the 'table-id' field to be at least
16 bits.  Now that we have VLANs and other types of virtual
interfaces, it would be nice to be able to have a routing table
for each interface, for example.  640k was not enough for everyone,
and ~250 routing tables isn't either :)


 From section 3.1.1:

    Table ID: 8 bits
    Table identifier.  Up to 255 route tables are supported.
                  RT_TABLE_UNSPEC    An unspecified routing table.
                  RT_TABLE_DEFAULT   The default table.
                  RT_TABLE_MAIN      The main table.
                  RT_TABLE_LOCAL     The local table.

                  The user may assign arbitrary values between
                  RT_TABLE_UNSPEC(0) and RT_TABLE_DEFAULT(253).

Thanks,
Ben


-- 
Ben Greear <greearb@candelatech.com>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear