commit f36b04125906b8f654a46650d83d7e17caa1e8d5
Author: dsp <dsp@2f30.org>
Date: Tue, 10 Feb 2015 19:15:16 -0700
initial commit
Diffstat:
16 files changed, 9410 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
@@ -0,0 +1,12 @@
+all: allbin
+
+test:
+ go test ./...
+
+allbin: cmd/archive_server.go
+ go build cmd/archive_server.go
+
+clean:
+ rm -f archive_server
+ go clean
+
diff --git a/README b/README
@@ -0,0 +1,60 @@
+=====================================================================
+ go-bgp by DsP <dsp@2f30.org>
+=====================================================================
+[General]
+go-bgp is a collection of pure golang libraries and tools for:
+reading and writing MRT files
+parsing BGP messages
+exposing archived BGP messages in various formats over RESTful HTTP/2
+
+[Details]
+mrt/
+ Using this module from golang allows you to open a file and then using
+ bufio to set the splitfunc to the provided SplitMrt
+ then using .Scan() you can get the []bytes of each MRT message
+
+
+archive/
+ This module allows the scanning of hierarchical dated dirs
+ that contain either XML encoded files or MRT files.
+ then it exposes an API that allows requests in the form of
+ http://host:port/archive?start=YYYYMMDDHHMMSS&end=YYYYMMDDHHMMSS&type=mrt
+ or
+ http://host:port/archive/conf?range
+ http://host:port/archive/conf?files
+
+monitor/
+ bgp monitor
+
+tests/
+ contain data for unit tests
+
+doc/
+ relevant RFCs
+
+cmd/
+ executable programs
+
+[License]
+Copyright (c) 2015, dsp <dsp@2f30.org>
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without modification,
+are permitted provided that the following conditions are met:
+
+1. Redistributions of source code must retain the above copyright notice,
+this list of conditions and the following disclaimer.
+
+2. Redistributions in binary form must reproduce the above copyright notice,
+this list of conditions and the following disclaimer in the documentation and/or
+other materials provided with the distribution.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
+ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY
+DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA,
+OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
+WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
+ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
diff --git a/archive/archive.go b/archive/archive.go
@@ -0,0 +1,607 @@
+package archive
+
+import (
+ "errors"
+ "fmt"
+ "log"
+ "net/http"
+ "net/url"
+ //"io/ioutil"
+ //"bytes"
+ "bufio"
+ "compress/bzip2"
+ mrt "go-bgp/mrt"
+ "io"
+ "os"
+ "path/filepath"
+ "sort"
+ "strconv"
+ "strings"
+ "sync"
+ "time"
+ "unicode"
+)
+
+const (
+ GET = "GET"
+ PUT = "PUT"
+ POST = "POST"
+ DELETE = "DELETE"
+)
+
+var (
+ errbadreq = errors.New("malformed request")
+ errbaddate = errors.New("dates should be in a YYYYMMDDHHMM format and start should be earlier than end")
+ errempty = errors.New("archive empty")
+ errdate = errors.New("no such date in archive")
+)
+
+type Resource interface {
+ Get(url.Values) (int, chan reply)
+ Put(url.Values) (int, chan reply)
+ Post(url.Values) (int, chan reply)
+ Delete(url.Values) (int, chan reply)
+}
+
+type (
+ GetNotAllowed struct{}
+ PutNotAllowed struct{}
+ PostNotAllowed struct{}
+ DeleteNotAllowed struct{}
+)
+
+func (GetNotAllowed) Get(vals url.Values) (int, chan reply) {
+ return 405, nil
+}
+
+func (PutNotAllowed) Put(vals url.Values) (int, chan reply) {
+ return 405, nil
+}
+func (PostNotAllowed) Post(vals url.Values) (int, chan reply) {
+ return 405, nil
+}
+func (DeleteNotAllowed) Delete(vals url.Values) (int, chan reply) {
+ return 405, nil
+}
+
+type API struct{}
+
+func (api *API) requestHandlerFunc(resource Resource) http.HandlerFunc {
+ return func(rw http.ResponseWriter, req *http.Request) {
+ var (
+ datac chan reply
+ code int
+ )
+ req.ParseForm()
+ method := req.Method
+ vals := req.Form
+ switch method {
+ case GET:
+ code, datac = resource.Get(vals)
+ case PUT:
+ code, datac = resource.Put(vals)
+ case POST:
+ code, datac = resource.Post(vals)
+ case DELETE:
+ code, datac = resource.Delete(vals)
+ }
+ rw.WriteHeader(code)
+ if datac != nil { // we got a proper channel to get datafrom
+ //go func(dc <-chan reply) { // fire a goroutine that will end upon the chan getting closed
+ for r := range datac {
+ if r.err == nil {
+ rw.Write(r.data)
+ } else {
+ log.Printf("Error in received from data channel:%s\n", r.err)
+ rw.Write([]byte(fmt.Sprintf("%s\n", r.err)))
+ }
+ }
+ //}(datac)
+ }
+ }
+}
+
+func (api *API) AddResource(resource Resource, path string) {
+ http.HandleFunc(path, api.requestHandlerFunc(resource))
+}
+
+func (api *API) Start(port int) {
+ portstr := fmt.Sprintf(":%d", port)
+ http.ListenAndServe(portstr, nil)
+}
+
+type reply struct {
+ data []byte
+ err error
+}
+
+//To perform a query asynchronously on possibly many files we fire multiple goroutines
+//that all write their results to chan reply, and we also need the waitgroup
+//to know when we should close the channel to end the http transaction
+type archive interface {
+ Query(time.Time, time.Time, chan reply, *sync.WaitGroup)
+ visit(string, os.FileInfo, error) error
+}
+
+type xmlstring struct {
+ timestr string
+ msg string
+ time time.Time
+}
+
+func (x *xmlstring) String() string {
+ return x.msg
+}
+
+//implements Sort interface by time.Time
+type archentryfile struct {
+ path string
+ sdate time.Time
+ sz int64
+}
+
+type timeentryslice []archentryfile
+
+func (p timeentryslice) Len() int {
+ return len(p)
+}
+
+func (p timeentryslice) Less(i, j int) bool {
+ return p[i].sdate.Before(p[j].sdate)
+}
+
+func (p timeentryslice) Swap(i, j int) {
+ p[i], p[j] = p[j], p[i]
+}
+
+type fsarchive struct {
+ rootpathstr string
+ entryfiles *timeentryslice
+ tempentryfiles timeentryslice
+ curyr int
+ curmon int
+ curday int
+ reqchan chan string
+ scanning bool
+ Scanwg *sync.WaitGroup // expose it so callers are able to wait for scan to finish
+ scanch chan struct{}
+ timedelta time.Duration
+ descriminator string
+ conf *fsarconf
+ //present tha archive as a restful resource
+ PutNotAllowed
+ PostNotAllowed
+ DeleteNotAllowed
+}
+
+type mrtarchive struct {
+ *fsarchive
+}
+
+type xmlarchive struct {
+ *fsarchive
+}
+
+type fsarconf struct {
+ arfiles *timeentryslice
+ PutNotAllowed
+ PostNotAllowed
+ DeleteNotAllowed
+}
+
+//in order not to block in gets, we need to
+//fire a new goroutine to send the reply on the channel
+// the reason is that we create the channel here and we must
+//return it to the responsewriter and any sends would block
+//without the receiver being ready.
+func (fsc *fsarconf) Get(values url.Values) (int, chan reply) {
+ retc := make(chan reply)
+ go func() {
+ defer close(retc) //must close the chan to let the listener finish.
+ if fsc.arfiles == nil {
+ log.Printf("nil arfile in fsarconf. ignoring request\n")
+ return
+ }
+ if _, ok := values["range"]; ok {
+ if len(*fsc.arfiles) > 0 {
+ f := *fsc.arfiles
+ dates := fmt.Sprintf("%s - %s\n", f[0].sdate, f[len(f)-1].sdate)
+ retc <- reply{data: []byte(dates), err: nil}
+ return
+ }
+ retc <- reply{data: nil, err: errempty}
+ return
+ }
+ if _, ok := values["files"]; ok {
+ for _, f := range *fsc.arfiles {
+ retc <- reply{data: []byte(fmt.Sprintf("%s\n", filepath.Base(f.path))), err: nil}
+ }
+ return
+ }
+ return
+ }()
+ return 200, retc
+}
+
+func (fsa *fsarchive) GetImpl(values url.Values, ar archive) (int, chan reply) {
+ var grwg sync.WaitGroup
+ retc := make(chan reply)
+ timeAstrs, ok1 := values["start"]
+ timeBstrs, ok2 := values["end"]
+ if len(timeAstrs) != len(timeBstrs) || !ok1 || !ok2 {
+ retc <- reply{data: nil, err: errbadreq}
+ goto done
+ }
+ for i := 0; i < len(timeAstrs); i++ {
+ log.Printf("timeAstr:%s timeBstr:%s", timeAstrs[i], timeBstrs[i])
+ timeA, errtime := time.Parse("200601021504", timeAstrs[i])
+ timeB, errtime := time.Parse("200601021504", timeBstrs[i])
+ if errtime != nil || timeB.Before(timeA) {
+ retc <- reply{data: nil, err: errbaddate}
+ } else {
+ //buf.WriteString(fmt.Sprintf("quering from t0:%s - t1:%s\n", timeA, timeB))
+ ar.Query(timeA, timeB, retc, &grwg) //this will fire a new goroutine
+ }
+ }
+ // the last goroutine that will wait for all we invoked and close the chan
+ go func(wg *sync.WaitGroup) {
+ wg.Wait() //wait for all the goroutines to finish sending
+ close(retc) //close the chan so that range in responsewriter will finish
+ log.Printf("closing the chan\n")
+ }(&grwg)
+done:
+ return 200, retc
+}
+
+func (fsa *mrtarchive) Get(values url.Values) (int, chan reply) {
+ return fsa.fsarchive.GetImpl(values, fsa)
+}
+
+func (fsa *xmlarchive) Get(values url.Values) (int, chan reply) {
+ return fsa.fsarchive.GetImpl(values, fsa)
+}
+
+func (ma *mrtarchive) Query(ta, tb time.Time, retc chan reply, wg *sync.WaitGroup) {
+ log.Printf("querying mrt from %s to %s\n", ta, tb)
+ go func(rc chan<- reply) {
+ wg.Add(1)
+ ef := *ma.entryfiles
+ var scanner *bufio.Scanner
+ defer wg.Done()
+ if len(ef) == 0 {
+ rc <- reply{nil, errempty}
+ return
+ }
+ if tb.Before(ef[0].sdate) || ta.After(ef[len(ef)-1].sdate.Add(ma.timedelta)) {
+ rc <- reply{nil, errdate}
+ return
+ }
+ i := sort.Search(len(ef), func(i int) bool {
+ return ef[i].sdate.After(ta.Add(-ma.timedelta - time.Second))
+ })
+ j := sort.Search(len(ef), func(i int) bool {
+ return ef[i].sdate.After(tb)
+ })
+ for k := i; k < j; k++ {
+ fext := filepath.Ext(ef[k].path)
+ file, ferr := os.Open(ef[k].path)
+ if ferr != nil {
+ log.Println("failed opening file: ", ef[k].path, " ", ferr)
+ continue
+ }
+ if fext == ".bz2" {
+ log.Printf("bunzip2 file. opening decompression stream\n")
+ bzreader := bzip2.NewReader(file)
+ scanner = bufio.NewScanner(bzreader)
+ scanner.Split(mrt.SplitMrt)
+ } else {
+ log.Printf("no extension on file: %s. opening normally\n", ef[k].path)
+ scanner = bufio.NewScanner(file)
+ scanner.Split(mrt.SplitMrt)
+ }
+ //buf.WriteString(fmt.Sprintf(" [ file: %s ] ", ef[k].path))
+ startt := time.Now()
+ for scanner.Scan() {
+ data := scanner.Bytes()
+ hdr, errh := mrt.NewMrtHdr(data[:mrt.MrtHdr_size])
+ if errh != nil {
+ log.Printf("error in creating MRT header:%s", errh)
+ rc <- reply{data: nil, err: errh}
+ continue
+ }
+ date := time.Unix(int64(hdr.Mrt_timestamp), 0)
+ log.Printf("scanned mrt with date:%s", date)
+ /*
+ dateindi := strings.Index(str, "<DATETIME>")
+ if dateindi == -1 {
+ log.Println("could not locate DATETIME string in xml msg: ", str)
+ continue
+ }
+ dateindi = dateindi + 10 // go to start of date data
+ dateindj := strings.Index(str[dateindi:], "</DATETIME>")
+ if dateindj == -1 {
+ log.Println("could not locate closing </DATETIME> string in xml msg: ", str)
+ continue
+ }
+ dateindj = dateindj + dateindi // to return it to the relative start of line pos
+ xmldate, derr := time.Parse(time.RFC3339, str[dateindi:dateindj])
+ if derr != nil {
+ log.Println("could not parse datetime: %s\n", derr)
+ continue
+ }
+ //log.Printf("parse xml message date: %s\n", xmldate)
+ if xmldate.After(ta) && xmldate.Before(tb) {
+ //buf.WriteString(fmt.Sprintf("%s\n",str))
+ rc <- reply{data: []byte(fmt.Sprintf("%s\n", str)), err: nil}
+ } else if xmldate.After(tb) { //only later measurements in this file. leaving
+ break
+ }*/
+ }
+ if err := scanner.Err(); err != nil && err != io.EOF {
+ log.Printf("file scanner error:%s\n", err)
+ }
+ log.Printf("finished parsing file %s size %d in %s\n", ef[k].path, ef[k].sz, time.Since(startt))
+ file.Close()
+ }
+ return
+ }(retc)
+}
+
+func (fsa *mrtarchive) visit(path string, f os.FileInfo, err error) error {
+ fname := f.Name()
+ log.Print("examining mrt: ", fname)
+ if strings.LastIndex(path, fsa.descriminator) == -1 {
+ log.Printf("visit: descriminator:%s not found in path:%s . ignoring\n", fsa.descriminator, path)
+ return nil
+ }
+ if f.Mode().IsRegular() {
+ numind := strings.IndexFunc(fname, unicode.IsDigit)
+ extind := strings.LastIndex(fname, ".bz2")
+ if numind == -1 || extind == -1 || extind-numind != 13 {
+ log.Print("file: ", fname, " not in foo.YYYYMMDD.HHMM.bz2... format. extind:%d numberind:%d", extind, numind)
+ return nil
+ }
+ datestr := fname[numind:extind]
+ log.Println("datestr in filename is ", datestr)
+ time, errtime := time.Parse("20060102.1504", datestr)
+ if errtime != nil {
+ log.Print("time.Parse() failed on file: ", fname, " that should be in fooHHMM format with error: ", errtime)
+ return nil
+ }
+ fsa.tempentryfiles = append(fsa.tempentryfiles, archentryfile{path: path, sdate: time, sz: f.Size()})
+ }
+ return nil
+}
+
+func (fsa *xmlarchive) Query(ta, tb time.Time, retc chan reply, wg *sync.WaitGroup) {
+ log.Printf("querying from %s to %s\n", ta, tb)
+ go func(rc chan<- reply) {
+ wg.Add(1)
+ defer wg.Done()
+ ef := *fsa.entryfiles
+ var scanner *bufio.Scanner
+ if len(ef) == 0 {
+ rc <- reply{nil, errempty}
+ return
+ }
+ if tb.Before(ef[0].sdate) || ta.After(ef[len(ef)-1].sdate.Add(fsa.timedelta)) {
+ rc <- reply{nil, errdate}
+ return
+ }
+ i := sort.Search(len(ef), func(i int) bool {
+ return ef[i].sdate.After(ta.Add(-fsa.timedelta - time.Second))
+ })
+ j := sort.Search(len(ef), func(i int) bool {
+ return ef[i].sdate.After(tb)
+ })
+ for k := i; k < j; k++ {
+ fext := filepath.Ext(ef[k].path)
+ file, ferr := os.Open(ef[k].path)
+ if ferr != nil {
+ log.Println("failed opening file: ", ef[k].path, " ", ferr)
+ continue
+ }
+ if fext == "" || fext == ".xml" {
+ log.Printf("no extension on file: %s. opening normally\n", ef[k].path)
+ scanner = bufio.NewScanner(file)
+ } else if fext == ".bz2" {
+ log.Printf("bunzip2 file. opening decompression stream\n")
+ bzreader := bzip2.NewReader(file)
+ scanner = bufio.NewScanner(bzreader)
+ } else {
+ log.Printf("unhandled file extension: %s\n", ef[j].path)
+ continue
+ }
+ //buf.WriteString(fmt.Sprintf(" [ file: %s ] ", ef[k].path))
+ startt := time.Now()
+ for scanner.Scan() {
+ str := scanner.Text()
+ dateindi := strings.Index(str, "<DATETIME>")
+ if dateindi == -1 {
+ log.Println("could not locate DATETIME string in xml msg: ", str)
+ continue
+ }
+ dateindi = dateindi + 10 // go to start of date data
+ dateindj := strings.Index(str[dateindi:], "</DATETIME>")
+ if dateindj == -1 {
+ log.Println("could not locate closing </DATETIME> string in xml msg: ", str)
+ continue
+ }
+ dateindj = dateindj + dateindi // to return it to the relative start of line pos
+ xmldate, derr := time.Parse(time.RFC3339, str[dateindi:dateindj])
+ if derr != nil {
+ log.Println("could not parse datetime: %s\n", derr)
+ continue
+ }
+ //log.Printf("parse xml message date: %s\n", xmldate)
+ if xmldate.After(ta) && xmldate.Before(tb) {
+ //buf.WriteString(fmt.Sprintf("%s\n",str))
+ rc <- reply{data: []byte(fmt.Sprintf("%s\n", str)), err: nil}
+ } else if xmldate.After(tb) { //only later measurements in this file. leaving
+ break
+ }
+ }
+ if err := scanner.Err(); err != nil && err != io.EOF {
+ log.Printf("file scanner error:%s\n", err)
+ }
+ log.Printf("finished parsing file %s size %d in %s\n", ef[k].path, ef[k].sz, time.Since(startt))
+ file.Close()
+ }
+ return
+ }(retc)
+}
+
+func NewMRTArchive(path, descr string) *mrtarchive {
+ return &mrtarchive{NewFsArchive(path, descr)}
+}
+
+func NewFsArchive(path, descr string) *fsarchive {
+ return &fsarchive{
+ rootpathstr: path,
+ entryfiles: &timeentryslice{},
+ tempentryfiles: timeentryslice{},
+ curyr: 0,
+ curmon: 0,
+ curday: 0,
+ reqchan: make(chan string),
+ scanning: false,
+ Scanwg: &sync.WaitGroup{},
+ scanch: make(chan struct{}),
+ timedelta: 15 * time.Minute,
+ descriminator: descr,
+ conf: &fsarconf{},
+ }
+}
+
+func NewXmlArchive(path, descr string) *xmlarchive {
+ return &xmlarchive{NewFsArchive(path, descr)}
+}
+
+//trying to see if a dir name is in YYYY.MM form
+//returns true, year, month if it is, or false, 0, 0 if not.
+func isYearMonthDir(fname string) (res bool, yr int, mon int) {
+ var err error
+ res = false
+ yr = 0
+ mon = 0
+ isdot := func(r rune) bool {
+ if r == '.' {
+ return true
+ }
+ return false
+ }
+ ind := strings.IndexFunc(fname, isdot)
+ //not found or in the form foo.
+ if ind == -1 || ind == len(fname) {
+ return
+ }
+ //not YYYY or MM
+ if len(fname[:ind]) != 4 || len(fname[ind+1:]) != 2 {
+ return
+ }
+ yr, err = strconv.Atoi(fname[:ind])
+ if err != nil {
+ return
+ }
+ mon, err = strconv.Atoi(fname[ind+1:])
+ if err != nil {
+ return
+ }
+ if mon < 1 || mon > 12 {
+ return
+ }
+ //the values were found to be valid
+ res = true
+ return
+}
+
+func (fsa *xmlarchive) visit(path string, f os.FileInfo, err error) error {
+ fname := f.Name()
+ log.Print("examining ", fname)
+ if strings.LastIndex(path, fsa.descriminator) == -1 {
+ log.Printf("visit: descriminator:%s not found in path:%s . ignoring\n", fsa.descriminator, path)
+ return nil
+ }
+
+ if f.Mode().IsRegular() {
+ numind := strings.IndexFunc(fname, unicode.IsDigit)
+ xmlind := strings.LastIndex(fname, ".xml")
+ if numind == -1 || xmlind == -1 || xmlind-numind != 13 {
+ log.Print("file: ", fname, " not in foo.YYYYMMDD.HHMM.xml... format")
+ return nil
+ }
+ datestr := fname[numind:xmlind]
+ log.Println("datestr in filename is ", datestr)
+ time, errtime := time.Parse("20060102.1504", datestr)
+ if errtime != nil {
+ log.Print("time.Parse() failed on file: ", fname, " that should be in fooHHMM format with error: ", errtime)
+ return nil
+ }
+ fsa.tempentryfiles = append(fsa.tempentryfiles, archentryfile{path: path, sdate: time, sz: f.Size()})
+ }
+ return nil
+}
+
+func (fsa *fsarchive) printEntries() {
+ log.Printf("dumping entries")
+ for _, ef := range *fsa.entryfiles {
+ fmt.Printf("%s %s\n", ef.path, ef.sdate)
+ }
+}
+
+func (fsa *fsarchive) scan(ar archive) {
+ //clear the temp slice
+ fsa.tempentryfiles = []archentryfile{}
+ fsa.Scanwg.Add(1)
+ fsa.scanning = true
+ filepath.Walk(fsa.rootpathstr, ar.visit)
+ sort.Sort(fsa.tempentryfiles)
+ //allow the serve goroutine to unblock in case of STOP.
+ fsa.Scanwg.Done()
+ //signal the serve goroutine on scandone channel
+ fsa.scanch <- struct{}{}
+}
+
+func (fsa *fsarchive) Serve(wg *sync.WaitGroup, ar archive) (reqchan chan<- string) {
+ if fsa.reqchan == nil { // we have closed the channel and now called again
+ fsa.reqchan = make(chan string)
+ }
+ wg.Add(1)
+ go func() {
+ defer wg.Done()
+ for {
+ select {
+ case req := <-fsa.reqchan:
+ switch req {
+ case "SCAN":
+ if fsa.scanning {
+ log.Print("fsarchive: already scanning. ignoring command")
+ } else { //fire an async goroutine to scan the files and wait for SCANDONE
+ go fsa.scan(ar)
+ }
+ case "DUMPENTRIES":
+ if fsa.scanning {
+ log.Print("fsar: warning. scanning in progress")
+ }
+ fsa.printEntries()
+ case "STOP":
+ log.Print("fsar: stopping")
+ fsa.Scanwg.Wait()
+ fsa.reqchan = nil //no more stuff from this channel
+ return
+ default:
+ log.Print("fsarchive: unknown request: ", req)
+ }
+ case <-fsa.scanch:
+ //update the reference to our file slice
+ fsa.entryfiles = &fsa.tempentryfiles
+ fsa.scanning = false
+ //let the config know
+ log.Printf("setting conf arfiles from :%v to a slice of len: %v\n", fsa.conf.arfiles, len(*fsa.entryfiles))
+ fsa.conf.arfiles = fsa.entryfiles
+ log.Print("fsarchive: scan finished")
+ }
+ }
+ }()
+ return fsa.reqchan
+}
diff --git a/bgp.go b/bgp.go
@@ -0,0 +1 @@
+package bgp
diff --git a/cmd/archive_server.go b/cmd/archive_server.go
@@ -0,0 +1,51 @@
+package main
+
+import (
+ ar "go-bgp/archive"
+ "log"
+ "os"
+ "sync"
+)
+
+func main() {
+ if len(os.Args) != 2 {
+ log.Fatal("usage: ", os.Args[0], " directory ")
+ }
+ basedirstr := os.Args[1]
+ ribmrtar := ar.NewMRTArchive(basedirstr, "RIBS")
+ wg1 := &sync.WaitGroup{}
+ mrtreqc := ribmrtar.Serve(wg1, ribmrtar)
+ mrtreqc <- "SCAN"
+ ribmrtar.Scanwg.Wait()
+ api := new(ar.API)
+ api.AddResource(ribmrtar, "/archive/mrt/ribs")
+ api.Start(3000)
+ close(mrtreqc)
+ wg1.Wait()
+ /*
+ updfsar := NewXmlArchive(basedirstr, "UPDATES")
+ //ribfsar := NewFsArchive(basedirstr, "RIBS")
+ wg2 := &sync.WaitGroup{}
+ updreqc := updfsar.serve(wg2, updfsar)
+ //ribreqc := updfsar.serve(wg2)
+ updreqc <- "SCAN"
+ updfsar.scanwg.Wait()
+ //ribfsar.scanwg.Wait()
+ //time.Sleep(time.Second*2)
+ updreqc <- "DUMPENTRIES"
+ api := new(API)
+ api.AddResource(updfsar, "/archive/updates")
+ //api.AddResource(ribfsar, "/archive/ribs")
+ api.AddResource(updfsar.conf, "/archive/updates/conf")
+ //api.AddResource(ribfsar.conf, "/archive/ribs/conf")
+ api.Start(3000)
+ //reqc<-"STOP"
+
+ close(updreqc)
+ //close(ribreqc)
+ //wait for it
+ //wg1.Wait()
+ wg2.Wait()
+ */
+ log.Print("all fsarchives stopped. exiting")
+}
diff --git a/doc/draft-ietf-grow-mrt-11.txt b/doc/draft-ietf-grow-mrt-11.txt
@@ -0,0 +1,1625 @@
+
+
+
+Network Working Group L. Blunk
+Internet-Draft M. Karir
+Intended status: Standards Track Merit Network
+Expires: September 9, 2010 C. Labovitz
+ Arbor Networks
+ March 8, 2010
+
+
+ MRT routing information export format
+ draft-ietf-grow-mrt-11.txt
+
+Abstract
+
+ This document describes the MRT format for routing information
+ export. This format was developed in concert with the Multi-threaded
+ Routing Toolkit (MRT) from whence the format takes it name. The
+ format can be used to export routing protocol messages, state
+ changes, and routing information base contents.
+
+Status of this Memo
+
+ This Internet-Draft is submitted to IETF in full conformance with the
+ provisions of BCP 78 and BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on September 9, 2010.
+
+Copyright Notice
+
+ Copyright (c) 2010 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+
+
+
+Blunk, et al. Expires September 9, 2010 [Page 1]
+
+Internet-Draft MRT Format March 2010
+
+
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blunk, et al. Expires September 9, 2010 [Page 2]
+
+Internet-Draft MRT Format March 2010
+
+
+Table of Contents
+
+ 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
+ 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3. Basic MRT Format . . . . . . . . . . . . . . . . . . . . . . . 6
+ 4. MRT Informational Types . . . . . . . . . . . . . . . . . . . 8
+ 4.1. START Type . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 4.2. I_AM_DEAD Type . . . . . . . . . . . . . . . . . . . . . . 8
+ 5. MRT Routing Information Types . . . . . . . . . . . . . . . . 9
+ 5.1. OSPF Type . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 5.2. TABLE_DUMP Type . . . . . . . . . . . . . . . . . . . . . 10
+ 5.3. TABLE_DUMP_V2 Type . . . . . . . . . . . . . . . . . . . . 11
+ 5.4. BGP4MP Type . . . . . . . . . . . . . . . . . . . . . . . 14
+ 5.4.1. BGP4MP_STATE_CHANGE Subtype . . . . . . . . . . . . . 14
+ 5.4.2. BGP4MP_MESSAGE Subtype . . . . . . . . . . . . . . . . 15
+ 5.4.3. BGP4MP_MESSAGE_AS4 Subtype . . . . . . . . . . . . . . 16
+ 5.4.4. BGP4MP_STATE_CHANGE_AS4 Subtype . . . . . . . . . . . 16
+ 5.4.5. BGP4MP_MESSAGE_LOCAL Subtype . . . . . . . . . . . . . 17
+ 5.4.6. BGP4MP_MESSAGE_AS4_LOCAL Subtype . . . . . . . . . . . 17
+ 5.5. BGP4MP_ET Type . . . . . . . . . . . . . . . . . . . . . . 17
+ 5.6. ISIS Type . . . . . . . . . . . . . . . . . . . . . . . . 18
+ 5.7. ISIS_ET Type . . . . . . . . . . . . . . . . . . . . . . . 18
+ 5.8. OSPFv3 Type . . . . . . . . . . . . . . . . . . . . . . . 18
+ 5.9. OSPFv3_ET Type . . . . . . . . . . . . . . . . . . . . . . 19
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
+ 6.1. Type Codes . . . . . . . . . . . . . . . . . . . . . . . . 20
+ 6.2. Subtype Codes . . . . . . . . . . . . . . . . . . . . . . 20
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
+ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
+ 8.1. Normative References . . . . . . . . . . . . . . . . . . . 22
+ 8.2. Informative References . . . . . . . . . . . . . . . . . . 22
+ Appendix A. Deprecated MRT types . . . . . . . . . . . . . . . . 23
+ A.1. Deprecated MRT Informational Types . . . . . . . . . . . . 23
+ A.1.1. NULL Type . . . . . . . . . . . . . . . . . . . . . . 23
+ A.1.2. DIE Type . . . . . . . . . . . . . . . . . . . . . . . 23
+ A.1.3. PEER_DOWN Type . . . . . . . . . . . . . . . . . . . . 23
+ A.2. Deprecated MRT Routing Information Types . . . . . . . . . 23
+ A.2.1. BGP Type . . . . . . . . . . . . . . . . . . . . . . . 23
+ A.2.2. RIP Type . . . . . . . . . . . . . . . . . . . . . . . 26
+ A.2.3. IDRP Type . . . . . . . . . . . . . . . . . . . . . . 26
+ A.2.4. RIPNG Type . . . . . . . . . . . . . . . . . . . . . . 26
+ A.2.5. BGP4PLUS and BGP4PLUS_01 Types . . . . . . . . . . . . 27
+ A.2.6. Deprecated BGP4MP Subtypes . . . . . . . . . . . . . . 27
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
+
+
+
+
+
+
+
+Blunk, et al. Expires September 9, 2010 [Page 3]
+
+Internet-Draft MRT Format March 2010
+
+
+1. Requirements notation
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blunk, et al. Expires September 9, 2010 [Page 4]
+
+Internet-Draft MRT Format March 2010
+
+
+2. Introduction
+
+ Researchers and engineers often wish to analyze network behavior by
+ studying routing protocol transactions and routing information base
+ snapshots. To this end, the MRT format was developed to encapsulate,
+ export, and archive this information in a standardized data
+ representation. The BGP routing protocol, in particular, has been
+ the subject of extensive study and analysis which has been
+ significantly aided by the availability of the MRT format. The MRT
+ format was initially defined in the MRT Programmer's Guide [MRT PROG
+ GUIDE].
+
+ This memo serves to document the MRT format as currently implemented
+ in publicly available software. The format has been extended since
+ it's original introduction in the MRT toolset and these extensions
+ are also included in this memo. Further extensions may be introduced
+ at a later date through additional definitions of the MRT Type field
+ and Subtype fields.
+
+ A number of MRT message types have been documented in some references
+ but are not known to have been implemented. Further, several types
+ were employed in early MRT implementations, but are no longer
+ actively being used. These types are considered to be deprecated and
+ are documented in a separate appendix at the end of this document.
+ Some of the deprecated types may of interest to researchers examining
+ historical MRT archives.
+
+ Fields which contain multi-octet numeric values are encoded in
+ network octet order from most significant octet to least significant
+ octet. Fields which contain routing message fields are encoded in
+ the same order as they appear in the packet contents.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blunk, et al. Expires September 9, 2010 [Page 5]
+
+Internet-Draft MRT Format March 2010
+
+
+3. Basic MRT Format
+
+ All MRT format messages have a common header which includes a
+ timestamp, Type, Subtype, and length field. The header is followed
+ by a message field. The MRT common header is illustrated below.
+
+ 0 1 2 3
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Timestamp |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Subtype |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Message... (variable)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Header Field Descriptions:
+
+
+ Timestamp:
+
+ Time in seconds since 1 January 1970 00:00:00 UTC
+
+
+ Type:
+
+ A 2-octet field that indicates the Type of information
+ contained in the message field. Types 0 through 4 are
+ informational messages pertaining to the state of an MRT
+ collector, while Types 5 and higher are used to convey routing
+ information.
+
+
+ Subtype:
+
+ A 2-octet field that is used to further distinguish message
+ information within a particular message Type.
+
+
+ Length:
+
+ A 4-octet message length field. The length field contains the
+ number of octets within the message. The length field does not
+ include the length of the MRT common header.
+
+
+
+
+
+Blunk, et al. Expires September 9, 2010 [Page 6]
+
+Internet-Draft MRT Format March 2010
+
+
+
+ Message:
+
+ A variable length message. The contents of this field are
+ context dependent upon the Type and Subtype fields.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blunk, et al. Expires September 9, 2010 [Page 7]
+
+Internet-Draft MRT Format March 2010
+
+
+4. MRT Informational Types
+
+ The MRT format defines five Informational Type messages. These
+ messages are intended to signal the state of an MRT data collector
+ and do not contain routing information. These messages are OPTIONAL
+ and were largely intended for use when MRT messages are sent over a
+ network to a remote repository store. However, MRT message
+ repository stores have traditionally resided on the same device as
+ the collector and these Informational Types have seen limited
+ implementation. Further, transport mechanisms for MRT messages are
+ considered to be outside the scope of this document.
+
+ The START and I_AM_DEAD messages MAY be used to provide a time
+ reference when a data collector begins and ends the collection
+ process. The time reference is obtained from the Timestamp field in
+ the MRT message header.
+
+ The message field MAY contain an OPTIONAL message string for
+ diagnostic purposes. The message string encoding MUST follow the
+ UTF-8 transformation format. The Subtype field is unused for these
+ Types and SHOULD be set to 0.
+
+ The MRT Informational Types are defined below:
+
+ 1 START
+ 3 I_AM_DEAD
+
+4.1. START Type
+
+ The START Type indicates a collector is about to begin generating MRT
+ messages.
+
+4.2. I_AM_DEAD Type
+
+ An I_AM_DEAD MRT message indicates that a collector has shut down and
+ has stopped generating MRT messages.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blunk, et al. Expires September 9, 2010 [Page 8]
+
+Internet-Draft MRT Format March 2010
+
+
+5. MRT Routing Information Types
+
+ The following Types are currently defined for the MRT format. Types
+ 11 and 12 were defined in the MRT Toolkit package. The BGP4MP Type,
+ number 16, was initially defined in the Zebra routing software
+ package. The BGP4MP_ET, ISIS, and ISIS_ET Types were initially
+ defined in the Sprint Labs Python Routing Toolkit (PyRT). The OSPFv3
+ and OSPFv3_ET Types are newly defined types created for the OSPFv3
+ routing protocol.
+
+ 11 OSPF
+ 12 TABLE_DUMP
+ 13 TABLE_DUMP_V2
+ 16 BGP4MP
+ 17 BGP4MP_ET
+ 32 ISIS
+ 33 ISIS_ET
+ 48 OSPFv3
+ 49 OSPFv3_ET
+
+5.1. OSPF Type
+
+ This Type supports the OSPF Protocol as defined in RFC 2328
+ [RFC2328]. The Subtype field may contain two possible values:
+
+ 0 OSPF_STATE_CHANGE
+ 1 OSPF_LSA_UPDATE
+
+ The format of the MRT Message field for the OSPF Type is as follows:
+
+ 0 1 2 3
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Remote IP address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Local IP address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | OSPF Message Contents (variable)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+
+
+
+Blunk, et al. Expires September 9, 2010 [Page 9]
+
+Internet-Draft MRT Format March 2010
+
+
+5.2. TABLE_DUMP Type
+
+ The TABLE_DUMP Type is used to encode the contents of a BGP Routing
+ Information Base (RIB). Each RIB entry is encoded in a distinct
+ sequential MRT record. The Subtype field is used to encode whether
+ the RIB entry contains IPv4 or IPv6 addresses. There are two
+ possible values for the Subtype as shown below.
+
+ 1 AFI_IPv4
+ 2 AFI_IPv6
+
+ The format of the TABLE_DUMP Type is illustrated below.
+
+ 0 1 2 3
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | View # | Sequence number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Prefix (variable) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Prefix Length | Status |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Originated Time |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Peer IP address (variable) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Peer AS | Attribute Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | BGP Attribute... (variable)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The View field is normally 0 and is intended for cases where an
+ implementation may have multiple RIB views (such as a route server).
+ In cases where multiple RIB views are present, an implementation may
+ use the the view field to distinguish entries from each view. The
+ Sequence field is a simple incremental counter for each RIB entry. A
+ typical RIB dump will exceed the 16-bit bounds of this counter and
+ implementation should simply wrap back to zero and continue
+ incrementing the counter in such cases.
+
+ The Prefix field contains the IP address of a particular RIB entry.
+ The size of this field is dependent on the value of the Subtype for
+ this message. For AFI_IPv4, this field is 4 octets, for AFI_IPv6, it
+ is 16 octets in length. The Prefix Length field indicates the length
+ in bits of the prefix mask for the preceding Prefix field.
+
+ The Status octet is not used in the TABLE_DUMP Type and SHOULD be set
+ to 1.
+
+
+
+Blunk, et al. Expires September 9, 2010 [Page 10]
+
+Internet-Draft MRT Format March 2010
+
+
+ The Originated Time contains the 4-octet time at which this prefix
+ was heard. The value represents the time in seconds since 1 January
+ 1970 00:00:00 UTC.
+
+ The Peer IP field is the IP address of the peer which provided the
+ update for this RIB entry. As with the Prefix field, the size of
+ this field is dependent on the Subtype. AFI_IPv4 indicates a 4 octet
+ field and an IPv4 address, while a Subtype of AFI_IPv6 requires a 16
+ octet field and an IPv6 address. The Peer AS field contains the AS
+ number of the peer.
+
+ Attribute length is the length of Attribute field and is 2-octets.
+ The Attribute field contains the attribute information for the RIB
+ entry.
+
+5.3. TABLE_DUMP_V2 Type
+
+ The TABLE_DUMP_V2 Type updates the TABLE_DUMP Type to include 4-Byte
+ ASN support and full support for BGP Multiprotocol extensions. It
+ also improves upon the space efficiency of the TABLE_DUMP Type by
+ employing an index table for peers and permitting a single MRT record
+ per NLRI entry. The following subtypes are used with the
+ TABLE_DUMP_V2 Type.
+
+ 1 PEER_INDEX_TABLE
+ 2 RIB_IPV4_UNICAST
+ 3 RIB_IPV4_MULTICAST
+ 4 RIB_IPV6_UNICAST
+ 5 RIB_IPV6_MULTICAST
+ 6 RIB_GENERIC
+
+ An initial PEER_INDEX_TABLE MRT record provides the BGP ID of the
+ collector, an optional view name, and a list of indexed peers.
+ Following the PEER_INDEX_TABLE MRT record, a series of MRT records
+ are used to encode RIB table entries. This series of MRT records use
+ subtypes 2-6 and are separate from the PEER_INDEX_TABLE MRT record
+ itself and include full MRT record headers. The header of the
+ PEER_INDEX_TABLE Subtype is shown below. The View Name is optional
+ and, if not present, the View Name Length MUST be set to 0. The View
+ Name encoding MUST follow the UTF-8 transformation format.
+
+
+
+
+
+
+
+
+
+
+
+Blunk, et al. Expires September 9, 2010 [Page 11]
+
+Internet-Draft MRT Format March 2010
+
+
+ 0 1 2 3
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Collector BGP ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | View Name Length | View Name (variable) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Peer Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The format of the peer entries is shown below. The PEER_INDEX_TABLE
+ record contains Peer Count peer entries.
+
+ 0 1 2 3
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Peer Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Peer BGP ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Peer IP address (variable) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Peer AS (variable) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The Peer Type, Peer BGP ID, Peer IP, and Peer AS fields are repeated
+ as indicated by the Peer Count field. The position of the Peer in
+ the PEER_INDEX_TABLE is used as an index in the subsequent
+ TABLE_DUMP_V2 MRT records. The index number begins with 0.
+
+ The Peer Type field is a bit field which encodes the type of the AS
+ and IP address as follows:
+
+ Bit 0 - unset for IPv4 Peer IP address, set for IPv6
+ Bit 1 - unset when Peer AS is 16 bits, set when it's 32 bits
+
+ The records which follow the PEER_INDEX_TABLE record constitute the
+ RIB entries and include a header which specifies a sequence number,
+ NLRI, and a count of the number of RIB entries which follow.
+
+ The format for the RIB_IPV4_UNICAST, RIB_IPV4_MULTICAST,
+ RIB_IPV6_UNICAST, and RIB_IPV6_MULTICAST headers are shown below.
+ The Prefix Length and Prefix fields are encoded in the same manner as
+ the BGP NLRI encoding for IPV4 and IPV6 prefixes. Namely, the Prefix
+ field contains address prefixes followed by enough trailing bits to
+ make the end of the field fall on an octet boundary. Note that the
+ value of trailing bits is irrelevant.
+
+
+
+
+Blunk, et al. Expires September 9, 2010 [Page 12]
+
+Internet-Draft MRT Format March 2010
+
+
+ 0 1 2 3
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Sequence number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Prefix Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Prefix (variable) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Entry Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The RIB_GENERIC header is shown below. It includes Address Family
+ Identifier (AFI), Subsequent AFI and a single NLRI entry. The NLRI
+ information is specific to the AFI and SAFI values. An
+ implementation which does not recognize particular AFI and SAFI
+ values SHOULD discard the remainder of the MRT record.
+
+ 0 1 2 3
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Sequence number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Address Family Identifier |Subsequent AFI |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Network Layer Reachability Information (variable) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Entry Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The RIB entry headers are followed by a series of RIB entries which
+ are repeated Entry Count times. These entries share a common format
+ as shown below. They include a Peer Index from the PEER_INDEX_TABLE
+ MRT record, an originated time for the RIB entry, and the BGP path
+ attribute length and attributes encoded as provided in a BGP Update
+ message.
+
+ 0 1 2 3
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Peer Index |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Originated Time |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Attribute Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | BGP Attributes... (variable)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+Blunk, et al. Expires September 9, 2010 [Page 13]
+
+Internet-Draft MRT Format March 2010
+
+
+ There is one exception to the encoding of BGP attributes for the BGP
+ MP_REACH_NLRI attribute (BGP Type Code 14) [RFC 4760]. Since the
+ AFI, SAFI, and NLRI information is already encoded in the
+ MULTIPROTOCOL header, only the Next Hop Address Length and Next Hop
+ Address fields are included. The Reserved field is omitted. The
+ attribute length is also adjusted to reflect only the length of the
+ Next Hop Address Length and Next Hop Address fields.
+
+5.4. BGP4MP Type
+
+ This Type was initially defined in the Zebra software package for the
+ BGP protocol with multiprotocol extension support as defined by RFC
+ 4760 [RFC4760]. It supersedes the BGP, BGP4PLUS, BGP4PLUS_01 Types.
+ The BGP4MP Type has six Subtypes which are defined as follows:
+
+ 0 BGP4MP_STATE_CHANGE
+ 1 BGP4MP_MESSAGE
+ 4 BGP4MP_MESSAGE_AS4
+ 5 BGP4MP_STATE_CHANGE_AS4
+ 6 BGP4MP_MESSAGE_LOCAL
+ 7 BGP4MP_MESSAGE_AS4_LOCAL
+
+5.4.1. BGP4MP_STATE_CHANGE Subtype
+
+ This record is used to encode state changes in the BGP finite state
+ machine. The BGP FSM states are encoded in the Old State and New
+ State fields to indicate the previous and current state. In some
+ cases, the Peer AS number may be undefined. In such cases, the value
+ of this field may be set to zero. The format is illustrated below:
+
+ 0 1 2 3
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Peer AS number | Local AS number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Interface Index | Address Family |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Peer IP address (variable) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Local IP address (variable) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Old State | New State |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+Blunk, et al. Expires September 9, 2010 [Page 14]
+
+Internet-Draft MRT Format March 2010
+
+
+ The FSM states are defined in RFC 4271 [RFC4271], Section 8.2.2.
+ Both the old state value and the new state value are encoded as
+ 2-octet numbers. The state values are defined numerically as
+ follows:
+
+ 1 Idle
+ 2 Connect
+ 3 Active
+ 4 OpenSent
+ 5 OpenConfirm
+ 6 Established
+
+ The BGP4MP_STATE_CHANGE message also includes interface index and
+ Address Family fields. The interface index provides the interface
+ number of the peering session. The index value is OPTIONAL and MAY
+ be zero if unknown or unsupported. The Address Family indicates what
+ types of addresses are in the the address fields. At present, the
+ following AFI Types are supported:
+
+ 1 AFI_IPv4
+ 2 AFI_IPv6
+
+5.4.2. BGP4MP_MESSAGE Subtype
+
+ This Subtype is used to encode BGP Messages. It can be used to
+ encode any Type of BGP message. The entire BGP message is
+ encapsulated in the BGP Message field, including the 16-octet marker,
+ the 2-octet length, and the 1-octet type fields. Note that the
+ BGP4MP_MESSAGE Subtype does not support 4-Byte AS numbers. Further,
+ the AS_PATH contained in these messages MUST only consist of 2-Byte
+ AS numbers. The BGP4MP_MESSAGE_AS4 Subtype updates the
+ BGP4MP_MESSAGE Subtype in order to support 4-Byte AS numbers. The
+ BGP4MP_MESSAGE fields are shown below:
+
+ 0 1 2 3
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Peer AS number | Local AS number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Interface Index | Address Family |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Peer IP address (variable) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Local IP address (variable) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | BGP Message... (variable)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+Blunk, et al. Expires September 9, 2010 [Page 15]
+
+Internet-Draft MRT Format March 2010
+
+
+ The interface index provides the interface number of the peering
+ session. The index value is OPTIONAL and MAY be zero if unknown or
+ unsupported. The Address Family indicates what types of addresses
+ are in the the subsequent address fields. At present, the following
+ AFI Types are supported:
+
+ 1 AFI_IPv4
+ 2 AFI_IPv6
+
+ Note that the Address Family value only applies to the IP addresses
+ contained in the MRT header. The BGP4MP_MESSAGE Subtype is otherwise
+ transparent to the contents of the actual message which may contain
+ any valid AFI/SAFI values. Only one BGP message may be encoded in
+ the BGP4MP_MESSAGE Subtype.
+
+5.4.3. BGP4MP_MESSAGE_AS4 Subtype
+
+ This Subtype updates the BGP4MP_MESSAGE Subtype to support 4-Byte
+ Autonomous System numbers. The BGP4MP_MESSAGE_AS4 Subtype is
+ otherwise identical to the BGP4MP_MESSAGE Subtype. The AS_PATH in
+ these messages MUST only consist of 4-Byte AS numbers. The
+ BGP4MP_MESSAGE_AS4 fields are shown below:
+
+ 0 1 2 3
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Peer AS number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Local AS number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Interface Index | Address Family |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Peer IP address (variable) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Local IP address (variable) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | BGP Message... (variable)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+5.4.4. BGP4MP_STATE_CHANGE_AS4 Subtype
+
+ This Subtype updates the BGP4MP_STATE_CHANGE Subtype to support
+ 4-Byte Autonomous System numbers. As with the BGP4MP_STATE_CHANGE
+ Subtype, the BGP FSM states are encoded in the Old State and New
+ State fields to indicate the previous and current state. Aside from
+ the extension of the peer and local AS fields to 4-Bytes, this
+ subtype is otherwise identical to the BGP4MP_STATE_CHANGE Subtype.
+ The BGP4MP_STATE_CHANGE_AS4 fields are shown below:
+
+
+
+Blunk, et al. Expires September 9, 2010 [Page 16]
+
+Internet-Draft MRT Format March 2010
+
+
+ 0 1 2 3
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Peer AS number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Local AS number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Interface Index | Address Family |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Peer IP address (variable) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Local IP address (variable) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Old State | New State |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+5.4.5. BGP4MP_MESSAGE_LOCAL Subtype
+
+ Implementations of MRT have largely focused on collecting remotely
+ generated BGP messages in a passive route collector role. However,
+ for active BGP implementations, it can be useful to archive locally
+ generated BGP messages in addition to remote messages. This subtype
+ is added to indicated a locally generated BGP message. The fields
+ remain identical to the BGP4MP_MESSAGE type including the Peer and
+ Local IP and AS fields. The Local fields continue to refer to the
+ local IP and AS number of the collector which generated the message
+ and the Peer IP and AS fields refer to the receipient of the
+ generated BGP messages.
+
+5.4.6. BGP4MP_MESSAGE_AS4_LOCAL Subtype
+
+ As with the BGP4MP_MESSAGE_LOCAL type, this type indicate locally
+ generated messages. The fields are identical to the
+ BGP4MP_MESSAGE_AS4 message type.
+
+5.5. BGP4MP_ET Type
+
+ This Type was initially defined in the Sprint Labs Python Routing
+ Toolkit (PyRT). It extends the MRT common header field to include a
+ 32BIT microsecond timestamp field. The type and subtype field
+ definitions remain as defined for the BGP4MP Type. The 32BIT
+ microsecond timestamp immediately follows the length field in the MRT
+ common header and precedes all other fields in the message. The
+ 32BIT microsecond field is included in the computation of the length
+ field value. The MRT common header modification is illustrated
+ below.
+
+
+
+
+
+Blunk, et al. Expires September 9, 2010 [Page 17]
+
+Internet-Draft MRT Format March 2010
+
+
+ 0 1 2 3
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Timestamp |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Subtype |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | microsecond timestamp |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Message... (variable)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+5.6. ISIS Type
+
+ This Type was initially defined in the Sprint Labs Python Routing and
+ supports the IS-IS routing protocol as defined in RFC 1195 [RFC1195].
+ There is no Type specific header for the ISIS Type. The Subtype code
+ for this Type is undefined. The ISIS PDU directly follows the MRT
+ common header fields.
+
+5.7. ISIS_ET Type
+
+ The ISIS_ET Type extends the ISIS Type to support microsecond
+ timestamps. As with the BGP4MP_ET Type, a 32BIT microsecond
+ timestamp field is appended to the MRT common header after the length
+ field. The ISIS_ET Type is otherwise identical to the ISIS Type.
+
+5.8. OSPFv3 Type
+
+ The OSPFv3 Type extends the original OSPF Type to support IPv6
+ addresses for the OSPFv3 protocol as defined in RFC 5340 [RFC5340].
+ The format of the MRT Message field for the OSPFv3 Type is as
+ follows:
+
+ 0 1 2 3
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Address Family |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Remote IP address (variable) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Local IP address (variable) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | OSPF Message Contents (variable)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+Blunk, et al. Expires September 9, 2010 [Page 18]
+
+Internet-Draft MRT Format March 2010
+
+
+5.9. OSPFv3_ET Type
+
+ The OSPFv3_ET Type extends the OSPFv3 Type to support microsecond
+ timestamps. As with the BGP4MP_ET Type, a 32BIT microsecond
+ timestamp field is appended to the MRT common header after the length
+ field and its length is included in the calculation of the length
+ field value. The OSPFv3_ET Type is otherwise identical to the OSPFv3
+ Type.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blunk, et al. Expires September 9, 2010 [Page 19]
+
+Internet-Draft MRT Format March 2010
+
+
+6. IANA Considerations
+
+ This section provides guidance to the Internet Assigned Numbers
+ Authority (IANA) regarding registration of values related to the MRT
+ specification, in accordance with BCP 26, RFC 5226 [RFC5226].
+
+ There are two name spaces in MRT that require registration: Type
+ Codes and Subtype Codes.
+
+ MRT is not intended as a general-purpose specification for protocol
+ information export, and allocations should not be made for purposes
+ unrelated to routing protocol information export.
+
+ The following policies are used here with the meanings defined in BCP
+ 26: "Specification Required", "IETF Consensus", "Experimental Use",
+ "First Come First Served".
+
+6.1. Type Codes
+
+ Type Codes have a range from 0 to 65535, of which 1-64 have been
+ allocated. New Type Codes MUST be allocated starting at 65. Type
+ Codes 65 - 511 are to be assigned by IETF Review. Type Codes 512 -
+ 2047 are assigned based on Specification Required. Type Codes 2048 -
+ 64511 are available on a First Come First Served policy. Type Codes
+ 64512 - 65534 are available for Experimental Use. The Type Code
+ Values of 0 and 65535 are reserved.
+
+6.2. Subtype Codes
+
+ Subtype Codes have a range from 0 to 65535. Subtype definitions are
+ specific to a particular Type Code definition. New Subtype Code
+ definition must reference an existing Type Code to which the Subtype
+ belongs. Subtype assignmnents to Type Codes 0 - 511 are to be
+ assigned by IETF Review. Subtype assignments for the remaning Type
+ Codes follow the assignment rules for the Type Codes to which they
+ belong.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blunk, et al. Expires September 9, 2010 [Page 20]
+
+Internet-Draft MRT Format March 2010
+
+
+7. Security Considerations
+
+ The MRT Format utilizes a structure which can store routing protocol
+ information data. The fields defined in the MRT specification are of
+ a descriptive nature and provide information that is useful to
+ facilitate the analysis of routing data. As such, the fields
+ currently defined in the MRT specification do not in themselves
+ create additional security risks, since the fields are not used to
+ induce any particular behavior by the recipient application.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blunk, et al. Expires September 9, 2010 [Page 21]
+
+Internet-Draft MRT Format March 2010
+
+
+8. References
+
+8.1. Normative References
+
+ [RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058,
+ June 1988.
+
+ [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
+ dual environments", RFC 1195, December 1990.
+
+ [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080,
+ January 1997.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
+
+ [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
+ Protocol 4 (BGP-4)", RFC 4271, January 2006.
+
+ [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
+ "Multiprotocol Extensions for BGP-4", RFC 4760,
+ January 2007.
+
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+ May 2008.
+
+ [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
+ for IPv6", RFC 5340, July 2008.
+
+8.2. Informative References
+
+ [MRT PROG GUIDE]
+ Labovitz, C., "MRT Programmer's Guide", November 1999,
+ <http://www.merit.edu/networkresearch/mrtprogrammer.pdf>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blunk, et al. Expires September 9, 2010 [Page 22]
+
+Internet-Draft MRT Format March 2010
+
+
+Appendix A. Deprecated MRT types
+
+ This Appendix lists deprecated MRT types. These types are documented
+ for informational purposes only. While documented in some
+ references, they are not known to have been generally implemented.
+
+A.1. Deprecated MRT Informational Types
+
+ The deprecated MRT Informational Types are defined below:
+
+ 0 NULL
+ 2 DIE
+ 4 PEER_DOWN
+
+A.1.1. NULL Type
+
+ The NULL Type message causes no operation.
+
+A.1.2. DIE Type
+
+ The DIE Type signals a remote MRT repository it should stop accepting
+ messages.
+
+A.1.3. PEER_DOWN Type
+
+ The PEER_DOWN message was intended to indicate that a collector had
+ lost association with a BGP peer. However, the MRT format provides
+ BGP state change message types which duplicate this functionality.
+
+A.2. Deprecated MRT Routing Information Types
+
+ 5 BGP
+ 6 RIP
+ 7 IDRP
+ 8 RIPNG
+ 9 BGP4PLUS
+ 10 BGP4PLUS_01
+
+A.2.1. BGP Type
+
+ The BGP Type indicates the Message field contains BGP routing
+ information. The BGP routing protocol is defined in RFC 4271
+ [RFC4271]. The information in the message is dependent on the
+ Subtype value. The BGP Type and all associated Subtypes below are
+ considered to be deprecated by the BGP4MP Type.
+
+ The following BGP Subtypes are defined for the MRT BGP Type. As with
+ the BGP Type itself, they are all considered to be deprecated.
+
+
+
+Blunk, et al. Expires September 9, 2010 [Page 23]
+
+Internet-Draft MRT Format March 2010
+
+
+ 0 BGP_NULL
+ 1 BGP_UPDATE
+ 2 BGP_PREF_UPDATE
+ 3 BGP_STATE_CHANGE
+ 4 BGP_SYNC
+ 5 BGP_OPEN
+ 6 BGP_NOTIFY
+ 7 BGP_KEEPALIVE
+
+A.2.1.1. BGP_NULL Subtype
+
+ The BGP_NULL Subtype is a reserved Subtype.
+
+A.2.1.2. BGP_UPDATE Subtype
+
+ The BGP_UPDATE Subtype is used to encode BGP UPDATE messages. The
+ format of the MRT Message field for this Subtype is as follows:
+
+ 0 1 2 3
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Peer AS number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Peer IP address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Local AS number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Local IP address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | BGP UPDATE Contents (variable)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The BGP UPDATE Contents include the entire BGP UPDATE message which
+ follows the BGP Message Header. The BGP Message Header itself is not
+ included. The Peer AS number and IP address fields contain the AS
+ number and IP address of the remote system which are generating the
+ BGP UPDATE messages. The Local AS number and IP address fields
+ contain the AS number and IP address of the local collector system
+ which is archiving the messages.
+
+A.2.1.3. BGP_PREF_UPDATE Subtype
+
+ The BGP_PREF_UPDATE Subtype is not defined.
+
+A.2.1.4. BGP_STATE_CHANGE Subtype
+
+ The BGP_STATE_CHANGE Subtype is used to record changes in the BGP
+ finite state machine. These FSM states are defined in RFC 4271
+
+
+
+Blunk, et al. Expires September 9, 2010 [Page 24]
+
+Internet-Draft MRT Format March 2010
+
+
+ [RFC4271], Section 8.2.2. Both the old state value and the new state
+ value are encoded as 2-octet numbers. The state values are defined
+ numerically as follows:
+
+ 1 Idle
+ 2 Connect
+ 3 Active
+ 4 OpenSent
+ 5 OpenConfirm
+ 6 Established
+
+ The format of the MRT Message field is as follows:
+
+ 0 1 2 3
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Peer AS number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Peer IP address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Old State | New State |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+A.2.1.5. BGP_SYNC Subtype
+
+ The BGP_SYNC Subtype was intended to convey a system file name where
+ BGP Table Dump messages should be recorded. The View # was to
+ correspond to the View # provided in the TABLE_DUMP Type messages.
+ There are no known implementations of this subtype and it SHOULD be
+ ignored. The following format applies to this Subtype:
+
+ 0 1 2 3
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | View # |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | File Name... (variable)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The File Name is terminated with a NULL (0) character.
+
+A.2.1.6. BGP_OPEN Subtype
+
+ The BGP_OPEN Subtype is used to encode BGP OPEN messages. The format
+ of the MRT Message field for this Subtype is the same as the
+ BGP_UPDATE, however, the last field contains the contents of the BGP
+ OPEN message.
+
+
+
+
+Blunk, et al. Expires September 9, 2010 [Page 25]
+
+Internet-Draft MRT Format March 2010
+
+
+A.2.1.7. BGP_NOTIFY Subtype
+
+ The BGP_NOTIFY Subtype is used to encode BGP NOTIFICATION messages.
+ The format of the MRT Message field for this Subtype is the same as
+ the BGP_UPDATE, however, the last field contains the contents of the
+ BGP NOTIFICATION message.
+
+A.2.1.8. BGP_KEEPALIVE Subtype
+
+ The BGP_KEEPALIVE Subtype is used to encode BGP KEEPALIVE messages.
+ The format of the MRT Message field for this Subtype is the same as
+ the BGP_UPDATE, however, the last field contains no information.
+
+A.2.2. RIP Type
+
+ The RIP Type is used to export RIP protocol packets as defined in RFC
+ 1058 [RFC1058]. The Subtype field is currently reserved for this
+ Type and SHOULD be set to 0.
+
+ The format of the MRT Message field for the RIP Type is as follows:
+
+ 0 1 2 3
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Peer IP address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Local IP address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | RIP Message Contents (variable)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+A.2.3. IDRP Type
+
+ The IDRP Type is used to export Inter-Domain-Routing Protocol (IDRP)
+ protocol information as defined in the ISO/IEC 10747 standard. The
+ Subtype field is unused. This Type is deprecated due to lack of
+ deployment of IDRP.
+
+A.2.4. RIPNG Type
+
+ The RIPNG Type is used to export RIPNG protocol packets as defined in
+ RFC 2080 [RFC2080]. The RIPNG protocol updates the RIP protocol to
+ support IPv6. The Subtype field is currently reserved for this Type
+ and SHOULD be set to 0.
+
+ The format of the MRT Message field for the RIPNG Type is as follows:
+
+
+
+
+
+Blunk, et al. Expires September 9, 2010 [Page 26]
+
+Internet-Draft MRT Format March 2010
+
+
+ 0 1 2 3
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ ~ Peer IPv6 address ~
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ ~ Local IPv6 address ~
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | RIPNG Message Contents (variable)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+A.2.5. BGP4PLUS and BGP4PLUS_01 Types
+
+ The BGP4PLUS and BGP4PLUS_01 Types were defined to support IPv6 BGP
+ routing information. The BGP4PLUS Type was specified based on the
+ initial Internet Draft for Multiprotocol Extensions to BGP-4. The
+ BGP4PLUS_01 Type was specified to correspond to the -01 revision of
+ this Internet Draft. The two Types share the same definitions in
+ terms of their MRT format specifications.
+
+ The Subtype field definitions are shared with the BGP Type, however,
+ the address fields in the BGP_UPDATE, BGP_OPEN, BGP_NOTIFY,
+ BGP_KEEPALIVE, and BGP_STATE_CHANGE Subtype messages are extended to
+ 16 octets for IPv6 addresses. As with the BGP Type, the BGP4PLUS and
+ BGP4PLUS_01 Types are deprecated as they superseded by the BGP4MP
+ Type.
+
+A.2.6. Deprecated BGP4MP Subtypes
+
+ The following two subtypes of the BGP4MP Type are considered to be
+ deprecated.
+
+ 2 BGP4MP_ENTRY
+ 3 BGP4MP_SNAPSHOT
+
+A.2.6.1. BGP4MP_ENTRY Subtype
+
+ This Subtype is similar to the TABLE_DUMP Type and is used to record
+ RIB table entries. It extends the TABLE_DUMP Type to include true
+ multiprotocol support. However, this Type does not support 4-Byte AS
+ numbers and has not been widely implemented. This Type is deprecated
+ in favor of the TABLE_DUMP_V2 which includes 4-Byte AS number support
+ and a more compact format.
+
+
+
+
+
+Blunk, et al. Expires September 9, 2010 [Page 27]
+
+Internet-Draft MRT Format March 2010
+
+
+ 0 1 2 3
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Peer AS number | Local AS number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Interface Index | Address Family |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Peer IP address (variable) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Local IP address (variable) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | View # | Status |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Time last change |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Address Family | SAFI | Next-Hop-Len |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Next Hop Address (variable) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Prefix Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Address Prefix (variable) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Attribute Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | BGP Attribute... (variable)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+A.2.6.2. BGP4MP_SNAPSHOT Subtype
+
+ This Subtype was intended to convey a system file name where
+ BGP4MP_ENTRY messages should be recorded. It is similar to the
+ BGP_SYNC message Subtype and is deprecated.
+
+ 0 1 2 3
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | View # |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | File Name... (variable)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+
+Blunk, et al. Expires September 9, 2010 [Page 28]
+
+Internet-Draft MRT Format March 2010
+
+
+Authors' Addresses
+
+ Larry Blunk
+ Merit Network
+
+ Email: ljb@merit.edu
+
+
+ Manish Karir
+ Merit Network
+
+ Email: mkarir@merit.edu
+
+
+ Craig Labovitz
+ Arbor Networks
+
+ Email: labovit@arbor.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blunk, et al. Expires September 9, 2010 [Page 29]
+
+
diff --git a/doc/rfc1771.txt b/doc/rfc1771.txt
@@ -0,0 +1,3195 @@
+
+
+
+
+
+
+Network Working Group Y. Rekhter
+Request for Comments: 1771 T.J. Watson Research Center, IBM Corp.
+Obsoletes: 1654 T. Li
+Category: Standards Track cisco Systems
+ Editors
+ March 1995
+
+
+ A Border Gateway Protocol 4 (BGP-4)
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Abstract
+
+ This document, together with its companion document, "Application of
+ the Border Gateway Protocol in the Internet", define an inter-
+ autonomous system routing protocol for the Internet.
+
+1. Acknowledgements
+
+ This document was originally published as RFC 1267 in October 1991,
+ jointly authored by Kirk Lougheed (cisco Systems) and Yakov Rekhter
+ (IBM).
+
+ We would like to express our thanks to Guy Almes (ANS), Len Bosack
+ (cisco Systems), and Jeffrey C. Honig (Cornell University) for their
+ contributions to the earlier version of this document.
+
+ We like to explicitly thank Bob Braden (ISI) for the review of the
+ earlier version of this document as well as his constructive and
+ valuable comments.
+
+ We would also like to thank Bob Hinden, Director for Routing of the
+ Internet Engineering Steering Group, and the team of reviewers he
+ assembled to review the previous version (BGP-2) of this document.
+ This team, consisting of Deborah Estrin, Milo Medin, John Moy, Radia
+ Perlman, Martha Steenstrup, Mike St. Johns, and Paul Tsuchiya, acted
+ with a strong combination of toughness, professionalism, and
+ courtesy.
+
+
+
+
+
+
+Rekhter & Li [Page 1]
+
+RFC 1771 BGP-4 March 1995
+
+
+ This updated version of the document is the product of the IETF IDR
+ Working Group with Yakov Rekhter and Tony Li as editors. Certain
+ sections of the document borrowed heavily from IDRP [7], which is the
+ OSI counterpart of BGP. For this credit should be given to the ANSI
+ X3S3.3 group chaired by Lyman Chapin (BBN) and to Charles Kunzinger
+ (IBM Corp.) who was the IDRP editor within that group. We would also
+ like to thank Mike Craren (Proteon, Inc.), Dimitry Haskin (Bay
+ Networks, Inc.), John Krawczyk (Bay Networks, Inc.), and Paul Traina
+ (cisco Systems) for their insightful comments.
+
+ We would like to specially acknowledge numerous contributions by
+ Dennis Ferguson (MCI).
+
+ The work of Yakov Rekhter was supported in part by the National
+ Science Foundation under Grant Number NCR-9219216.
+
+2. Introduction
+
+ The Border Gateway Protocol (BGP) is an inter-Autonomous System
+ routing protocol. It is built on experience gained with EGP as
+ defined in RFC 904 [1] and EGP usage in the NSFNET Backbone as
+ described in RFC 1092 [2] and RFC 1093 [3].
+
+ The primary function of a BGP speaking system is to exchange network
+ reachability information with other BGP systems. This network
+ reachability information includes information on the list of
+ Autonomous Systems (ASs) that reachability information traverses.
+ This information is sufficient to construct a graph of AS
+ connectivity from which routing loops may be pruned and some policy
+ decisions at the AS level may be enforced.
+
+ BGP-4 provides a new set of mechanisms for supporting classless
+ interdomain routing. These mechanisms include support for
+ advertising an IP prefix and eliminates the concept of network
+ "class" within BGP. BGP-4 also introduces mechanisms which allow
+ aggregation of routes, including aggregation of AS paths. These
+ changes provide support for the proposed supernetting scheme [8, 9].
+
+ To characterize the set of policy decisions that can be enforced
+ using BGP, one must focus on the rule that a BGP speaker advertise to
+ its peers (other BGP speakers which it communicates with) in
+ neighboring ASs only those routes that it itself uses. This rule
+ reflects the "hop-by-hop" routing paradigm generally used throughout
+ the current Internet. Note that some policies cannot be supported by
+ the "hop-by-hop" routing paradigm and thus require techniques such as
+ source routing to enforce. For example, BGP does not enable one AS
+ to send traffic to a neighboring AS intending that the traffic take a
+ different route from that taken by traffic originating in the
+
+
+
+Rekhter & Li [Page 2]
+
+RFC 1771 BGP-4 March 1995
+
+
+ neighboring AS. On the other hand, BGP can support any policy
+ conforming to the "hop-by-hop" routing paradigm. Since the current
+ Internet uses only the "hop-by-hop" routing paradigm and since BGP
+ can support any policy that conforms to that paradigm, BGP is highly
+ applicable as an inter-AS routing protocol for the current Internet.
+
+ A more complete discussion of what policies can and cannot be
+ enforced with BGP is outside the scope of this document (but refer to
+ the companion document discussing BGP usage [5]).
+
+ BGP runs over a reliable transport protocol. This eliminates the
+ need to implement explicit update fragmentation, retransmission,
+ acknowledgement, and sequencing. Any authentication scheme used by
+ the transport protocol may be used in addition to BGP's own
+ authentication mechanisms. The error notification mechanism used in
+ BGP assumes that the transport protocol supports a "graceful" close,
+ i.e., that all outstanding data will be delivered before the
+ connection is closed.
+
+ BGP uses TCP [4] as its transport protocol. TCP meets BGP's
+ transport requirements and is present in virtually all commercial
+ routers and hosts. In the following descriptions the phrase
+ "transport protocol connection" can be understood to refer to a TCP
+ connection. BGP uses TCP port 179 for establishing its connections.
+
+ This document uses the term `Autonomous System' (AS) throughout. The
+ classic definition of an Autonomous System is a set of routers under
+ a single technical administration, using an interior gateway protocol
+ and common metrics to route packets within the AS, and using an
+ exterior gateway protocol to route packets to other ASs. Since this
+ classic definition was developed, it has become common for a single
+ AS to use several interior gateway protocols and sometimes several
+ sets of metrics within an AS. The use of the term Autonomous System
+ here stresses the fact that, even when multiple IGPs and metrics are
+ used, the administration of an AS appears to other ASs to have a
+ single coherent interior routing plan and presents a consistent
+ picture of what destinations are reachable through it.
+
+ The planned use of BGP in the Internet environment, including such
+ issues as topology, the interaction between BGP and IGPs, and the
+ enforcement of routing policy rules is presented in a companion
+ document [5]. This document is the first of a series of documents
+ planned to explore various aspects of BGP application. Please send
+ comments to the BGP mailing list (bgp@ans.net).
+
+
+
+
+
+
+
+Rekhter & Li [Page 3]
+
+RFC 1771 BGP-4 March 1995
+
+
+3. Summary of Operation
+
+ Two systems form a transport protocol connection between one another.
+ They exchange messages to open and confirm the connection parameters.
+ The initial data flow is the entire BGP routing table. Incremental
+ updates are sent as the routing tables change. BGP does not require
+ periodic refresh of the entire BGP routing table. Therefore, a BGP
+ speaker must retain the current version of the entire BGP routing
+ tables of all of its peers for the duration of the connection.
+ KeepAlive messages are sent periodically to ensure the liveness of
+ the connection. Notification messages are sent in response to errors
+ or special conditions. If a connection encounters an error
+ condition, a notification message is sent and the connection is
+ closed.
+
+ The hosts executing the Border Gateway Protocol need not be routers.
+ A non-routing host could exchange routing information with routers
+ via EGP or even an interior routing protocol. That non-routing host
+ could then use BGP to exchange routing information with a border
+ router in another Autonomous System. The implications and
+ applications of this architecture are for further study.
+
+ If a particular AS has multiple BGP speakers and is providing transit
+ service for other ASs, then care must be taken to ensure a consistent
+ view of routing within the AS. A consistent view of the interior
+ routes of the AS is provided by the interior routing protocol. A
+ consistent view of the routes exterior to the AS can be provided by
+ having all BGP speakers within the AS maintain direct BGP connections
+ with each other. Using a common set of policies, the BGP speakers
+ arrive at an agreement as to which border routers will serve as
+ exit/entry points for particular destinations outside the AS. This
+ information is communicated to the AS's internal routers, possibly
+ via the interior routing protocol. Care must be taken to ensure that
+ the interior routers have all been updated with transit information
+ before the BGP speakers announce to other ASs that transit service is
+ being provided.
+
+ Connections between BGP speakers of different ASs are referred to as
+ "external" links. BGP connections between BGP speakers within the
+ same AS are referred to as "internal" links. Similarly, a peer in a
+ different AS is referred to as an external peer, while a peer in the
+ same AS may be described as an internal peer.
+
+
+
+
+
+
+
+
+
+Rekhter & Li [Page 4]
+
+RFC 1771 BGP-4 March 1995
+
+
+3.1 Routes: Advertisement and Storage
+
+ For purposes of this protocol a route is defined as a unit of
+ information that pairs a destination with the attributes of a path to
+ that destination:
+
+ - Routes are advertised between a pair of BGP speakers in UPDATE
+ messages: the destination is the systems whose IP addresses are
+ reported in the Network Layer Reachability Information (NLRI)
+ field, and the the path is the information reported in the path
+ attributes fields of the same UPDATE message.
+
+ - Routes are stored in the Routing Information Bases (RIBs):
+ namely, the Adj-RIBs-In, the Loc-RIB, and the Adj-RIBs-Out. Routes
+ that will be advertised to other BGP speakers must be present in
+ the Adj-RIB-Out; routes that will be used by the local BGP speaker
+ must be present in the Loc-RIB, and the next hop for each of these
+ routes must be present in the local BGP speaker's forwarding
+ information base; and routes that are received from other BGP
+ speakers are present in the Adj-RIBs-In.
+
+ If a BGP speaker chooses to advertise the route, it may add to or
+ modify the path attributes of the route before advertising it to a
+ peer.
+
+ BGP provides mechanisms by which a BGP speaker can inform its peer
+ that a previously advertised route is no longer available for use.
+ There are three methods by which a given BGP speaker can indicate
+ that a route has been withdrawn from service:
+
+ a) the IP prefix that expresses destinations for a previously
+ advertised route can be advertised in the WITHDRAWN ROUTES field
+ in the UPDATE message, thus marking the associated route as being
+ no longer available for use
+
+ b) a replacement route with the same Network Layer Reachability
+ Information can be advertised, or
+
+ c) the BGP speaker - BGP speaker connection can be closed, which
+ implicitly removes from service all routes which the pair of
+ speakers had advertised to each other.
+
+
+
+
+
+
+
+
+
+
+Rekhter & Li [Page 5]
+
+RFC 1771 BGP-4 March 1995
+
+
+3.2 Routing Information Bases
+
+ The Routing Information Base (RIB) within a BGP speaker consists of
+ three distinct parts:
+
+ a) Adj-RIBs-In: The Adj-RIBs-In store routing information that has
+ been learned from inbound UPDATE messages. Their contents
+ represent routes that are available as an input to the Decision
+ Process.
+
+ b) Loc-RIB: The Loc-RIB contains the local routing information
+ that the BGP speaker has selected by applying its local policies
+ to the routing information contained in its Adj-RIBs-In.
+
+ c) Adj-RIBs-Out: The Adj-RIBs-Out store the information that the
+ local BGP speaker has selected for advertisement to its peers. The
+ routing information stored in the Adj-RIBs-Out will be carried in
+ the local BGP speaker's UPDATE messages and advertised to its
+ peers.
+
+ In summary, the Adj-RIBs-In contain unprocessed routing information
+ that has been advertised to the local BGP speaker by its peers; the
+ Loc-RIB contains the routes that have been selected by the local BGP
+ speaker's Decision Process; and the Adj-RIBs-Out organize the routes
+ for advertisement to specific peers by means of the local speaker's
+ UPDATE messages.
+
+ Although the conceptual model distinguishes between Adj-RIBs-In,
+ Loc-RIB, and Adj-RIBs-Out, this neither implies nor requires that an
+ implementation must maintain three separate copies of the routing
+ information. The choice of implementation (for example, 3 copies of
+ the information vs 1 copy with pointers) is not constrained by the
+ protocol.
+
+4. Message Formats
+
+ This section describes message formats used by BGP.
+
+ Messages are sent over a reliable transport protocol connection. A
+ message is processed only after it is entirely received. The maximum
+ message size is 4096 octets. All implementations are required to
+ support this maximum message size. The smallest message that may be
+ sent consists of a BGP header without a data portion, or 19 octets.
+
+
+
+
+
+
+
+
+Rekhter & Li [Page 6]
+
+RFC 1771 BGP-4 March 1995
+
+
+4.1 Message Header Format
+
+ Each message has a fixed-size header. There may or may not be a data
+ portion following the header, depending on the message type. The
+ layout of these fields is shown below:
+
+ 0 1 2 3
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + +
+ | |
+ + +
+ | Marker |
+ + +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Length | Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Marker:
+
+ This 16-octet field contains a value that the receiver of the
+ message can predict. If the Type of the message is OPEN, or if
+ the OPEN message carries no Authentication Information (as an
+ Optional Parameter), then the Marker must be all ones.
+ Otherwise, the value of the marker can be predicted by some a
+ computation specified as part of the authentication mechanism
+ (which is specified as part of the Authentication Information)
+ used. The Marker can be used to detect loss of synchronization
+ between a pair of BGP peers, and to authenticate incoming BGP
+ messages.
+
+ Length:
+
+ This 2-octet unsigned integer indicates the total length of the
+ message, including the header, in octets. Thus, e.g., it
+ allows one to locate in the transport-level stream the (Marker
+ field of the) next message. The value of the Length field must
+ always be at least 19 and no greater than 4096, and may be
+ further constrained, depending on the message type. No
+ "padding" of extra data after the message is allowed, so the
+ Length field must have the smallest value required given the
+ rest of the message.
+
+
+
+
+
+
+
+Rekhter & Li [Page 7]
+
+RFC 1771 BGP-4 March 1995
+
+
+ Type:
+
+ This 1-octet unsigned integer indicates the type code of the
+ message. The following type codes are defined:
+
+ 1 - OPEN
+ 2 - UPDATE
+ 3 - NOTIFICATION
+ 4 - KEEPALIVE
+
+4.2 OPEN Message Format
+
+ After a transport protocol connection is established, the first
+ message sent by each side is an OPEN message. If the OPEN message is
+ acceptable, a KEEPALIVE message confirming the OPEN is sent back.
+ Once the OPEN is confirmed, UPDATE, KEEPALIVE, and NOTIFICATION
+ messages may be exchanged.
+
+ In addition to the fixed-size BGP header, the OPEN message contains
+ the following fields:
+
+ 0 1 2 3
+ 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
+ +-+-+-+-+-+-+-+-+
+ | Version |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | My Autonomous System |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Hold Time |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | BGP Identifier |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Opt Parm Len |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ | Optional Parameters |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Version:
+
+ This 1-octet unsigned integer indicates the protocol version
+ number of the message. The current BGP version number is 4.
+
+ My Autonomous System:
+
+ This 2-octet unsigned integer indicates the Autonomous System
+ number of the sender.
+
+
+
+Rekhter & Li [Page 8]
+
+RFC 1771 BGP-4 March 1995
+
+
+ Hold Time:
+
+ This 2-octet unsigned integer indicates the number of seconds
+ that the sender proposes for the value of the Hold Timer. Upon
+ receipt of an OPEN message, a BGP speaker MUST calculate the
+ value of the Hold Timer by using the smaller of its configured
+ Hold Time and the Hold Time received in the OPEN message. The
+ Hold Time MUST be either zero or at least three seconds. An
+ implementation may reject connections on the basis of the Hold
+ Time. The calculated value indicates the maximum number of
+ seconds that may elapse between the receipt of successive
+ KEEPALIVE, and/or UPDATE messages by the sender.
+
+ BGP Identifier:
+
+ This 4-octet unsigned integer indicates the BGP Identifier of
+ the sender. A given BGP speaker sets the value of its BGP
+ Identifier to an IP address assigned to that BGP speaker. The
+ value of the BGP Identifier is determined on startup and is the
+ same for every local interface and every BGP peer.
+
+ Optional Parameters Length:
+
+ This 1-octet unsigned integer indicates the total length of the
+ Optional Parameters field in octets. If the value of this field
+ is zero, no Optional Parameters are present.
+
+ Optional Parameters:
+
+ This field may contain a list of optional parameters, where
+ each parameter is encoded as a <Parameter Type, Parameter
+ Length, Parameter Value> triplet.
+
+ 0 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
+ | Parm. Type | Parm. Length | Parameter Value (variable)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
+
+ Parameter Type is a one octet field that unambiguously
+ identifies individual parameters. Parameter Length is a one
+ octet field that contains the length of the Parameter Value
+ field in octets. Parameter Value is a variable length field
+ that is interpreted according to the value of the Parameter
+ Type field.
+
+
+
+
+
+
+Rekhter & Li [Page 9]
+
+RFC 1771 BGP-4 March 1995
+
+
+ This document defines the following Optional Parameters:
+
+ a) Authentication Information (Parameter Type 1):
+
+ This optional parameter may be used to authenticate a BGP
+ peer. The Parameter Value field contains a 1-octet
+ Authentication Code followed by a variable length
+ Authentication Data.
+
+ 0 1 2 3 4 5 6 7 8
+ +-+-+-+-+-+-+-+-+
+ | Auth. Code |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ | Authentication Data |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Authentication Code:
+
+ This 1-octet unsigned integer indicates the
+ authentication mechanism being used. Whenever an
+ authentication mechanism is specified for use within
+ BGP, three things must be included in the
+ specification:
+
+ - the value of the Authentication Code which indicates
+ use of the mechanism,
+ - the form and meaning of the Authentication Data, and
+ - the algorithm for computing values of Marker fields.
+
+ Note that a separate authentication mechanism may be
+ used in establishing the transport level connection.
+
+ Authentication Data:
+
+ The form and meaning of this field is a variable-
+ length field depend on the Authentication Code.
+
+ The minimum length of the OPEN message is 29 octets (including
+ message header).
+
+
+
+
+
+
+
+
+
+
+Rekhter & Li [Page 10]
+
+RFC 1771 BGP-4 March 1995
+
+
+4.3 UPDATE Message Format
+
+ UPDATE messages are used to transfer routing information between BGP
+ peers. The information in the UPDATE packet can be used to construct
+ a graph describing the relationships of the various Autonomous
+ Systems. By applying rules to be discussed, routing information
+ loops and some other anomalies may be detected and removed from
+ inter-AS routing.
+
+ An UPDATE message is used to advertise a single feasible route to a
+ peer, or to withdraw multiple unfeasible routes from service (see
+ 3.1). An UPDATE message may simultaneously advertise a feasible route
+ and withdraw multiple unfeasible routes from service. The UPDATE
+ message always includes the fixed-size BGP header, and can optionally
+ include the other fields as shown below:
+
+ +-----------------------------------------------------+
+ | Unfeasible Routes Length (2 octets) |
+ +-----------------------------------------------------+
+ | Withdrawn Routes (variable) |
+ +-----------------------------------------------------+
+ | Total Path Attribute Length (2 octets) |
+ +-----------------------------------------------------+
+ | Path Attributes (variable) |
+ +-----------------------------------------------------+
+ | Network Layer Reachability Information (variable) |
+ +-----------------------------------------------------+
+
+ Unfeasible Routes Length:
+
+ This 2-octets unsigned integer indicates the total length of
+ the Withdrawn Routes field in octets. Its value must allow the
+ length of the Network Layer Reachability Information field to
+ be determined as specified below.
+
+ A value of 0 indicates that no routes are being withdrawn from
+ service, and that the WITHDRAWN ROUTES field is not present in
+ this UPDATE message.
+
+ Withdrawn Routes:
+
+ This is a variable length field that contains a list of IP
+ address prefixes for the routes that are being withdrawn from
+ service. Each IP address prefix is encoded as a 2-tuple of the
+ form <length, prefix>, whose fields are described below:
+
+
+
+
+
+
+Rekhter & Li [Page 11]
+
+RFC 1771 BGP-4 March 1995
+
+
+ +---------------------------+
+ | Length (1 octet) |
+ +---------------------------+
+ | Prefix (variable) |
+ +---------------------------+
+
+ The use and the meaning of these fields are as follows:
+
+ a) Length:
+
+ The Length field indicates the length in bits of the IP
+ address prefix. A length of zero indicates a prefix that
+ matches all IP addresses (with prefix, itself, of zero
+ octets).
+
+ b) Prefix:
+
+ The Prefix field contains IP address prefixes followed by
+ enough trailing bits to make the end of the field fall on an
+ octet boundary. Note that the value of trailing bits is
+ irrelevant.
+
+ Total Path Attribute Length:
+
+ This 2-octet unsigned integer indicates the total length of the
+ Path Attributes field in octets. Its value must allow the
+ length of the Network Layer Reachability field to be determined
+ as specified below.
+
+ A value of 0 indicates that no Network Layer Reachability
+ Information field is present in this UPDATE message.
+
+ Path Attributes:
+
+ A variable length sequence of path attributes is present in
+ every UPDATE. Each path attribute is a triple <attribute type,
+ attribute length, attribute value> of variable length.
+
+ Attribute Type is a two-octet field that consists of the
+ Attribute Flags octet followed by the Attribute Type Code
+ octet.
+
+ 0 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Attr. Flags |Attr. Type Code|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+Rekhter & Li [Page 12]
+
+RFC 1771 BGP-4 March 1995
+
+
+ The high-order bit (bit 0) of the Attribute Flags octet is the
+ Optional bit. It defines whether the attribute is optional (if
+ set to 1) or well-known (if set to 0).
+
+ The second high-order bit (bit 1) of the Attribute Flags octet
+ is the Transitive bit. It defines whether an optional
+ attribute is transitive (if set to 1) or non-transitive (if set
+ to 0). For well-known attributes, the Transitive bit must be
+ set to 1. (See Section 5 for a discussion of transitive
+ attributes.)
+
+ The third high-order bit (bit 2) of the Attribute Flags octet
+ is the Partial bit. It defines whether the information
+ contained in the optional transitive attribute is partial (if
+ set to 1) or complete (if set to 0). For well-known attributes
+ and for optional non-transitive attributes the Partial bit must
+ be set to 0.
+
+ The fourth high-order bit (bit 3) of the Attribute Flags octet
+ is the Extended Length bit. It defines whether the Attribute
+ Length is one octet (if set to 0) or two octets (if set to 1).
+ Extended Length may be used only if the length of the attribute
+ value is greater than 255 octets.
+
+ The lower-order four bits of the Attribute Flags octet are .
+ unused. They must be zero (and must be ignored when received).
+
+ The Attribute Type Code octet contains the Attribute Type Code.
+ Currently defined Attribute Type Codes are discussed in Section
+ 5.
+
+ If the Extended Length bit of the Attribute Flags octet is set
+ to 0, the third octet of the Path Attribute contains the length
+ of the attribute data in octets.
+
+ If the Extended Length bit of the Attribute Flags octet is set
+ to 1, then the third and the fourth octets of the path
+ attribute contain the length of the attribute data in octets.
+
+ The remaining octets of the Path Attribute represent the
+ attribute value and are interpreted according to the Attribute
+ Flags and the Attribute Type Code. The supported Attribute Type
+ Codes, their attribute values and uses are the following:
+
+
+
+
+
+
+
+
+Rekhter & Li [Page 13]
+
+RFC 1771 BGP-4 March 1995
+
+
+ a) ORIGIN (Type Code 1):
+
+ ORIGIN is a well-known mandatory attribute that defines the
+ origin of the path information. The data octet can assume
+ the following values:
+
+ Value Meaning
+
+ 0 IGP - Network Layer Reachability Information
+ is interior to the originating AS
+
+ 1 EGP - Network Layer Reachability Information
+ learned via EGP
+
+ 2 INCOMPLETE - Network Layer Reachability
+ Information learned by some other means
+
+ Its usage is defined in 5.1.1
+
+ b) AS_PATH (Type Code 2):
+
+ AS_PATH is a well-known mandatory attribute that is composed
+ of a sequence of AS path segments. Each AS path segment is
+ represented by a triple <path segment type, path segment
+ length, path segment value>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rekhter & Li [Page 14]
+
+RFC 1771 BGP-4 March 1995
+
+
+ The path segment type is a 1-octet long field with the
+ following values defined:
+
+ Value Segment Type
+
+ 1 AS_SET: unordered set of ASs a route in the
+ UPDATE message has traversed
+
+ 2 AS_SEQUENCE: ordered set of ASs a route in
+ the UPDATE message has traversed
+
+ The path segment length is a 1-octet long field containing
+ the number of ASs in the path segment value field.
+
+ The path segment value field contains one or more AS
+ numbers, each encoded as a 2-octets long field.
+
+ Usage of this attribute is defined in 5.1.2.
+
+ c) NEXT_HOP (Type Code 3):
+
+ This is a well-known mandatory attribute that defines the IP
+ address of the border router that should be used as the next
+ hop to the destinations listed in the Network Layer
+ Reachability field of the UPDATE message.
+
+ Usage of this attribute is defined in 5.1.3.
+
+ d) MULTI_EXIT_DISC (Type Code 4):
+
+ This is an optional non-transitive attribute that is a four
+ octet non-negative integer. The value of this attribute may
+ be used by a BGP speaker's decision process to discriminate
+ among multiple exit points to a neighboring autonomous
+ system.
+
+ Its usage is defined in 5.1.4.
+
+ e) LOCAL_PREF (Type Code 5):
+
+ LOCAL_PREF is a well-known discretionary attribute that is a
+ four octet non-negative integer. It is used by a BGP speaker
+ to inform other BGP speakers in its own autonomous system of
+ the originating speaker's degree of preference for an
+ advertised route. Usage of this attribute is described in
+ 5.1.5.
+
+
+
+
+
+Rekhter & Li [Page 15]
+
+RFC 1771 BGP-4 March 1995
+
+
+ f) ATOMIC_AGGREGATE (Type Code 6)
+
+ ATOMIC_AGGREGATE is a well-known discretionary attribute of
+ length 0. It is used by a BGP speaker to inform other BGP
+ speakers that the local system selected a less specific
+ route without selecting a more specific route which is
+ included in it. Usage of this attribute is described in
+ 5.1.6.
+
+ g) AGGREGATOR (Type Code 7)
+
+ AGGREGATOR is an optional transitive attribute of length 6.
+ The attribute contains the last AS number that formed the
+ aggregate route (encoded as 2 octets), followed by the IP
+ address of the BGP speaker that formed the aggregate route
+ (encoded as 4 octets). Usage of this attribute is described
+ in 5.1.7
+
+ Network Layer Reachability Information:
+
+ This variable length field contains a list of IP address
+ prefixes. The length in octets of the Network Layer
+ Reachability Information is not encoded explicitly, but can be
+ calculated as:
+
+ UPDATE message Length - 23 - Total Path Attributes Length -
+ Unfeasible Routes Length
+
+ where UPDATE message Length is the value encoded in the fixed-
+ size BGP header, Total Path Attribute Length and Unfeasible
+ Routes Length are the values encoded in the variable part of
+ the UPDATE message, and 23 is a combined length of the fixed-
+ size BGP header, the Total Path Attribute Length field and the
+ Unfeasible Routes Length field.
+
+ Reachability information is encoded as one or more 2-tuples of
+ the form <length, prefix>, whose fields are described below:
+
+ +---------------------------+
+ | Length (1 octet) |
+ +---------------------------+
+ | Prefix (variable) |
+ +---------------------------+
+
+
+
+
+
+
+
+
+Rekhter & Li [Page 16]
+
+RFC 1771 BGP-4 March 1995
+
+
+ The use and the meaning of these fields are as follows:
+
+ a) Length:
+
+ The Length field indicates the length in bits of the IP
+ address prefix. A length of zero indicates a prefix that
+ matches all IP addresses (with prefix, itself, of zero
+ octets).
+
+ b) Prefix:
+
+ The Prefix field contains IP address prefixes followed by
+ enough trailing bits to make the end of the field fall on an
+ octet boundary. Note that the value of the trailing bits is
+ irrelevant.
+
+ The minimum length of the UPDATE message is 23 octets -- 19 octets
+ for the fixed header + 2 octets for the Unfeasible Routes Length + 2
+ octets for the Total Path Attribute Length (the value of Unfeasible
+ Routes Length is 0 and the value of Total Path Attribute Length is
+ 0).
+
+ An UPDATE message can advertise at most one route, which may be
+ described by several path attributes. All path attributes contained
+ in a given UPDATE messages apply to the destinations carried in the
+ Network Layer Reachability Information field of the UPDATE message.
+
+ An UPDATE message can list multiple routes to be withdrawn from
+ service. Each such route is identified by its destination (expressed
+ as an IP prefix), which unambiguously identifies the route in the
+ context of the BGP speaker - BGP speaker connection to which it has
+ been previously been advertised.
+
+ An UPDATE message may advertise only routes to be withdrawn from
+ service, in which case it will not include path attributes or Network
+ Layer Reachability Information. Conversely, it may advertise only a
+ feasible route, in which case the WITHDRAWN ROUTES field need not be
+ present.
+
+4.4 KEEPALIVE Message Format
+
+ BGP does not use any transport protocol-based keep-alive mechanism to
+ determine if peers are reachable. Instead, KEEPALIVE messages are
+ exchanged between peers often enough as not to cause the Hold Timer
+ to expire. A reasonable maximum time between KEEPALIVE messages
+ would be one third of the Hold Time interval. KEEPALIVE messages
+ MUST NOT be sent more frequently than one per second. An
+ implementation MAY adjust the rate at which it sends KEEPALIVE
+
+
+
+Rekhter & Li [Page 17]
+
+RFC 1771 BGP-4 March 1995
+
+
+ messages as a function of the Hold Time interval.
+
+ If the negotiated Hold Time interval is zero, then periodic KEEPALIVE
+ messages MUST NOT be sent.
+
+ KEEPALIVE message consists of only message header and has a length of
+ 19 octets.
+
+4.5 NOTIFICATION Message Format
+
+ A NOTIFICATION message is sent when an error condition is detected.
+ The BGP connection is closed immediately after sending it.
+
+ In addition to the fixed-size BGP header, the NOTIFICATION message
+ contains the following fields:
+
+ 0 1 2 3
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Error code | Error subcode | Data |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Error Code:
+
+ This 1-octet unsigned integer indicates the type of
+ NOTIFICATION. The following Error Codes have been defined:
+
+ Error Code Symbolic Name Reference
+
+ 1 Message Header Error Section 6.1
+
+ 2 OPEN Message Error Section 6.2
+
+ 3 UPDATE Message Error Section 6.3
+
+ 4 Hold Timer Expired Section 6.5
+
+ 5 Finite State Machine Error Section 6.6
+
+ 6 Cease Section 6.7
+
+ Error subcode:
+
+ This 1-octet unsigned integer provides more specific
+ information about the nature of the reported error. Each Error
+ Code may have one or more Error Subcodes associated with it.
+
+
+
+Rekhter & Li [Page 18]
+
+RFC 1771 BGP-4 March 1995
+
+
+ If no appropriate Error Subcode is defined, then a zero
+ (Unspecific) value is used for the Error Subcode field.
+
+ Message Header Error subcodes:
+
+ 1 - Connection Not Synchronized.
+ 2 - Bad Message Length.
+ 3 - Bad Message Type.
+
+ OPEN Message Error subcodes:
+
+ 1 - Unsupported Version Number.
+ 2 - Bad Peer AS.
+ 3 - Bad BGP Identifier. '
+ 4 - Unsupported Optional Parameter.
+ 5 - Authentication Failure.
+ 6 - Unacceptable Hold Time.
+
+ UPDATE Message Error subcodes:
+
+ 1 - Malformed Attribute List.
+ 2 - Unrecognized Well-known Attribute.
+ 3 - Missing Well-known Attribute.
+ 4 - Attribute Flags Error.
+ 5 - Attribute Length Error.
+ 6 - Invalid ORIGIN Attribute
+ 7 - AS Routing Loop.
+ 8 - Invalid NEXT_HOP Attribute.
+ 9 - Optional Attribute Error.
+ 10 - Invalid Network Field.
+ 11 - Malformed AS_PATH.
+
+ Data:
+
+ This variable-length field is used to diagnose the reason for
+ the NOTIFICATION. The contents of the Data field depend upon
+ the Error Code and Error Subcode. See Section 6 below for more
+ details.
+
+ Note that the length of the Data field can be determined from
+ the message Length field by the formula:
+
+ Message Length = 21 + Data Length
+
+ The minimum length of the NOTIFICATION message is 21 octets
+ (including message header).
+
+
+
+
+
+Rekhter & Li [Page 19]
+
+RFC 1771 BGP-4 March 1995
+
+
+5. Path Attributes
+
+ This section discusses the path attributes of the UPDATE message.
+
+ Path attributes fall into four separate categories:
+
+ 1. Well-known mandatory.
+ 2. Well-known discretionary.
+ 3. Optional transitive.
+ 4. Optional non-transitive.
+
+ Well-known attributes must be recognized by all BGP implementations.
+ Some of these attributes are mandatory and must be included in every
+ UPDATE message. Others are discretionary and may or may not be sent
+ in a particular UPDATE message.
+
+ All well-known attributes must be passed along (after proper
+ updating, if necessary) to other BGP peers.
+
+ In addition to well-known attributes, each path may contain one or
+ more optional attributes. It is not required or expected that all
+ BGP implementations support all optional attributes. The handling of
+ an unrecognized optional attribute is determined by the setting of
+ the Transitive bit in the attribute flags octet. Paths with
+ unrecognized transitive optional attributes should be accepted. If a
+ path with unrecognized transitive optional attribute is accepted and
+ passed along to other BGP peers, then the unrecognized transitive
+ optional attribute of that path must be passed along with the path to
+ other BGP peers with the Partial bit in the Attribute Flags octet set
+ to 1. If a path with recognized transitive optional attribute is
+ accepted and passed along to other BGP peers and the Partial bit in
+ the Attribute Flags octet is set to 1 by some previous AS, it is not
+ set back to 0 by the current AS. Unrecognized non-transitive optional
+ attributes must be quietly ignored and not passed along to other BGP
+ peers.
+
+ New transitive optional attributes may be attached to the path by the
+ originator or by any other AS in the path. If they are not attached
+ by the originator, the Partial bit in the Attribute Flags octet is
+ set to 1. The rules for attaching new non-transitive optional
+ attributes will depend on the nature of the specific attribute. The
+ documentation of each new non-transitive optional attribute will be
+ expected to include such rules. (The description of the
+ MULTI_EXIT_DISC attribute gives an example.) All optional attributes
+ (both transitive and non-transitive) may be updated (if appropriate)
+ by ASs in the path.
+
+
+
+
+
+Rekhter & Li [Page 20]
+
+RFC 1771 BGP-4 March 1995
+
+
+ The sender of an UPDATE message should order path attributes within
+ the UPDATE message in ascending order of attribute type. The
+ receiver of an UPDATE message must be prepared to handle path
+ attributes within the UPDATE message that are out of order.
+
+ The same attribute cannot appear more than once within the Path
+ Attributes field of a particular UPDATE message.
+
+5.1 Path Attribute Usage
+
+ The usage of each BGP path attributes is described in the following
+ clauses.
+
+5.1.1 ORIGIN
+
+ ORIGIN is a well-known mandatory attribute. The ORIGIN attribute
+ shall be generated by the autonomous system that originates the
+ associated routing information. It shall be included in the UPDATE
+ messages of all BGP speakers that choose to propagate this
+ information to other BGP speakers.
+
+5.1.2 AS_PATH
+
+ AS_PATH is a well-known mandatory attribute. This attribute
+ identifies the autonomous systems through which routing information
+ carried in this UPDATE message has passed. The components of this
+ list can be AS_SETs or AS_SEQUENCEs.
+
+ When a BGP speaker propagates a route which it has learned from
+ another BGP speaker's UPDATE message, it shall modify the route's
+ AS_PATH attribute based on the location of the BGP speaker to which
+ the route will be sent:
+
+ a) When a given BGP speaker advertises the route to another BGP
+ speaker located in its own autonomous system, the advertising
+ speaker shall not modify the AS_PATH attribute associated with the
+ route.
+
+ b) When a given BGP speaker advertises the route to a BGP speaker
+ located in a neighboring autonomous system, then the advertising
+ speaker shall update the AS_PATH attribute as follows:
+
+ 1) if the first path segment of the AS_PATH is of type
+ AS_SEQUENCE, the local system shall prepend its own AS number
+ as the last element of the sequence (put it in the leftmost
+ position).
+
+
+
+
+
+Rekhter & Li [Page 21]
+
+RFC 1771 BGP-4 March 1995
+
+
+ 2) if the first path segment of the AS_PATH is of type AS_SET,
+ the local system shall prepend a new path segment of type
+ AS_SEQUENCE to the AS_PATH, including its own AS number in that
+ segment.
+
+ When a BGP speaker originates a route then:
+
+ a) the originating speaker shall include its own AS number in
+ the AS_PATH attribute of all UPDATE messages sent to BGP
+ speakers located in neighboring autonomous systems. (In this
+ case, the AS number of the originating speaker's autonomous
+ system will be the only entry in the AS_PATH attribute).
+
+ b) the originating speaker shall include an empty AS_PATH
+ attribute in all UPDATE messages sent to BGP speakers located
+ in its own autonomous system. (An empty AS_PATH attribute is
+ one whose length field contains the value zero).
+
+5.1.3 NEXT_HOP
+
+ The NEXT_HOP path attribute defines the IP address of the border
+ router that should be used as the next hop to the destinations listed
+ in the UPDATE message. If a border router belongs to the same AS as
+ its peer, then the peer is an internal border router. Otherwise, it
+ is an external border router. A BGP speaker can advertise any
+ internal border router as the next hop provided that the interface
+ associated with the IP address of this border router (as specified in
+ the NEXT_HOP path attribute) shares a common subnet with both the
+ local and remote BGP speakers. A BGP speaker can advertise any
+ external border router as the next hop, provided that the IP address
+ of this border router was learned from one of the BGP speaker's
+ peers, and the interface associated with the IP address of this
+ border router (as specified in the NEXT_HOP path attribute) shares a
+ common subnet with the local and remote BGP speakers. A BGP speaker
+ needs to be able to support disabling advertisement of external
+ border routers.
+
+ A BGP speaker must never advertise an address of a peer to that peer
+ as a NEXT_HOP, for a route that the speaker is originating. A BGP
+ speaker must never install a route with itself as the next hop.
+
+ When a BGP speaker advertises the route to a BGP speaker located in
+ its own autonomous system, the advertising speaker shall not modify
+ the NEXT_HOP attribute associated with the route. When a BGP speaker
+ receives the route via an internal link, it may forward packets to
+ the NEXT_HOP address if the address contained in the attribute is on
+ a common subnet with the local and remote BGP speakers.
+
+
+
+
+Rekhter & Li [Page 22]
+
+RFC 1771 BGP-4 March 1995
+
+
+5.1.4 MULTI_EXIT_DISC
+
+ The MULTI_EXIT_DISC attribute may be used on external (inter-AS)
+ links to discriminate among multiple exit or entry points to the same
+ neighboring AS. The value of the MULTI_EXIT_DISC attribute is a four
+ octet unsigned number which is called a metric. All other factors
+ being equal, the exit or entry point with lower metric should be
+ preferred. If received over external links, the MULTI_EXIT_DISC
+ attribute may be propagated over internal links to other BGP speakers
+ within the same AS. The MULTI_EXIT_DISC attribute is never
+ propagated to other BGP speakers in neighboring AS's.
+
+5.1.5 LOCAL_PREF
+
+ LOCAL_PREF is a well-known discretionary attribute that shall be
+ included in all UPDATE messages that a given BGP speaker sends to the
+ other BGP speakers located in its own autonomous system. A BGP
+ speaker shall calculate the degree of preference for each external
+ route and include the degree of preference when advertising a route
+ to its internal peers. The higher degree of preference should be
+ preferred. A BGP speaker shall use the degree of preference learned
+ via LOCAL_PREF in its decision process (see section 9.1.1).
+
+ A BGP speaker shall not include this attribute in UPDATE messages
+ that it sends to BGP speakers located in a neighboring autonomous
+ system. If it is contained in an UPDATE message that is received from
+ a BGP speaker which is not located in the same autonomous system as
+ the receiving speaker, then this attribute shall be ignored by the
+ receiving speaker.
+
+5.1.6 ATOMIC_AGGREGATE
+
+ ATOMIC_AGGREGATE is a well-known discretionary attribute. If a BGP
+ speaker, when presented with a set of overlapping routes from one of
+ its peers (see 9.1.4), selects the less specific route without
+ selecting the more specific one, then the local system shall attach
+ the ATOMIC_AGGREGATE attribute to the route when propagating it to
+ other BGP speakers (if that attribute is not already present in the
+ received less specific route). A BGP speaker that receives a route
+ with the ATOMIC_AGGREGATE attribute shall not remove the attribute
+ from the route when propagating it to other speakers. A BGP speaker
+ that receives a route with the ATOMIC_AGGREGATE attribute shall not
+ make any NLRI of that route more specific (as defined in 9.1.4) when
+ advertising this route to other BGP speakers. A BGP speaker that
+ receives a route with the ATOMIC_AGGREGATE attribute needs to be
+ cognizant of the fact that the actual path to destinations, as
+ specified in the NLRI of the route, while having the loop-free
+ property, may traverse ASs that are not listed in the AS_PATH
+
+
+
+Rekhter & Li [Page 23]
+
+RFC 1771 BGP-4 March 1995
+
+
+ attribute.
+
+5.1.7 AGGREGATOR
+
+ AGGREGATOR is an optional transitive attribute which may be included
+ in updates which are formed by aggregation (see Section 9.2.4.2). A
+ BGP speaker which performs route aggregation may add the AGGREGATOR
+ attribute which shall contain its own AS number and IP address.
+
+6. BGP Error Handling.
+
+ This section describes actions to be taken when errors are detected
+ while processing BGP messages.
+
+ When any of the conditions described here are detected, a
+ NOTIFICATION message with the indicated Error Code, Error Subcode,
+ and Data fields is sent, and the BGP connection is closed. If no
+ Error Subcode is specified, then a zero must be used.
+
+ The phrase "the BGP connection is closed" means that the transport
+ protocol connection has been closed and that all resources for that
+ BGP connection have been deallocated. Routing table entries
+ associated with the remote peer are marked as invalid. The fact that
+ the routes have become invalid is passed to other BGP peers before
+ the routes are deleted from the system.
+
+ Unless specified explicitly, the Data field of the NOTIFICATION
+ message that is sent to indicate an error is empty.
+
+6.1 Message Header error handling.
+
+ All errors detected while processing the Message Header are indicated
+ by sending the NOTIFICATION message with Error Code Message Header
+ Error. The Error Subcode elaborates on the specific nature of the
+ error.
+
+ The expected value of the Marker field of the message header is all
+ ones if the message type is OPEN. The expected value of the Marker
+ field for all other types of BGP messages determined based on the
+ presence of the Authentication Information Optional Parameter in the
+ BGP OPEN message and the actual authentication mechanism (if the
+ Authentication Information in the BGP OPEN message is present). If
+ the Marker field of the message header is not the expected one, then
+ a synchronization error has occurred and the Error Subcode is set to
+ Connection Not Synchronized.
+
+
+
+
+
+
+Rekhter & Li [Page 24]
+
+RFC 1771 BGP-4 March 1995
+
+
+ If the Length field of the message header is less than 19 or greater
+ than 4096, or if the Length field of an OPEN message is less than
+ the minimum length of the OPEN message, or if the Length field of an
+ UPDATE message is less than the minimum length of the UPDATE message,
+ or if the Length field of a KEEPALIVE message is not equal to 19, or
+ if the Length field of a NOTIFICATION message is less than the
+ minimum length of the NOTIFICATION message, then the Error Subcode is
+ set to Bad Message Length. The Data field contains the erroneous
+ Length field.
+
+ If the Type field of the message header is not recognized, then the
+ Error Subcode is set to Bad Message Type. The Data field contains
+ the erroneous Type field.
+
+6.2 OPEN message error handling.
+
+ All errors detected while processing the OPEN message are indicated
+ by sending the NOTIFICATION message with Error Code OPEN Message
+ Error. The Error Subcode elaborates on the specific nature of the
+ error.
+
+ If the version number contained in the Version field of the received
+ OPEN message is not supported, then the Error Subcode is set to
+ Unsupported Version Number. The Data field is a 2-octet unsigned
+ integer, which indicates the largest locally supported version number
+ less than the version the remote BGP peer bid (as indicated in the
+ received OPEN message).
+
+ If the Autonomous System field of the OPEN message is unacceptable,
+ then the Error Subcode is set to Bad Peer AS. The determination of
+ acceptable Autonomous System numbers is outside the scope of this
+ protocol.
+
+ If the Hold Time field of the OPEN message is unacceptable, then the
+ Error Subcode MUST be set to Unacceptable Hold Time. An
+ implementation MUST reject Hold Time values of one or two seconds.
+ An implementation MAY reject any proposed Hold Time. An
+ implementation which accepts a Hold Time MUST use the negotiated
+ value for the Hold Time.
+
+ If the BGP Identifier field of the OPEN message is syntactically
+ incorrect, then the Error Subcode is set to Bad BGP Identifier.
+ Syntactic correctness means that the BGP Identifier field represents
+ a valid IP host address.
+
+ If one of the Optional Parameters in the OPEN message is not
+ recognized, then the Error Subcode is set to Unsupported Optional
+ Parameters.
+
+
+
+Rekhter & Li [Page 25]
+
+RFC 1771 BGP-4 March 1995
+
+
+ If the OPEN message carries Authentication Information (as an
+ Optional Parameter), then the corresponding authentication procedure
+ is invoked. If the authentication procedure (based on Authentication
+ Code and Authentication Data) fails, then the Error Subcode is set to
+ Authentication Failure.
+
+6.3 UPDATE message error handling.
+
+ All errors detected while processing the UPDATE message are indicated
+ by sending the NOTIFICATION message with Error Code UPDATE Message
+ Error. The error subcode elaborates on the specific nature of the
+ error.
+
+ Error checking of an UPDATE message begins by examining the path
+ attributes. If the Unfeasible Routes Length or Total Attribute
+ Length is too large (i.e., if Unfeasible Routes Length + Total
+ Attribute Length + 23 exceeds the message Length), then the Error
+ Subcode is set to Malformed Attribute List.
+
+ If any recognized attribute has Attribute Flags that conflict with
+ the Attribute Type Code, then the Error Subcode is set to Attribute
+ Flags Error. The Data field contains the erroneous attribute (type,
+ length and value).
+
+ If any recognized attribute has Attribute Length that conflicts with
+ the expected length (based on the attribute type code), then the
+ Error Subcode is set to Attribute Length Error. The Data field
+ contains the erroneous attribute (type, length and value).
+
+ If any of the mandatory well-known attributes are not present, then
+ the Error Subcode is set to Missing Well-known Attribute. The Data
+ field contains the Attribute Type Code of the missing well-known
+ attribute.
+
+ If any of the mandatory well-known attributes are not recognized,
+ then the Error Subcode is set to Unrecognized Well-known Attribute.
+ The Data field contains the unrecognized attribute (type, length and
+ value).
+
+ If the ORIGIN attribute has an undefined value, then the Error
+ Subcode is set to Invalid Origin Attribute. The Data field contains
+ the unrecognized attribute (type, length and value).
+
+ If the NEXT_HOP attribute field is syntactically incorrect, then the
+ Error Subcode is set to Invalid NEXT_HOP Attribute. The Data field
+ contains the incorrect attribute (type, length and value). Syntactic
+ correctness means that the NEXT_HOP attribute represents a valid IP
+ host address. Semantic correctness applies only to the external BGP
+
+
+
+Rekhter & Li [Page 26]
+
+RFC 1771 BGP-4 March 1995
+
+
+ links. It means that the interface associated with the IP address, as
+ specified in the NEXT_HOP attribute, shares a common subnet with the
+ receiving BGP speaker and is not the IP address of the receiving BGP
+ speaker. If the NEXT_HOP attribute is semantically incorrect, the
+ error should be logged, and the the route should be ignored. In this
+ case, no NOTIFICATION message should be sent.
+
+ The AS_PATH attribute is checked for syntactic correctness. If the
+ path is syntactically incorrect, then the Error Subcode is set to
+ Malformed AS_PATH.
+
+ If an optional attribute is recognized, then the value of this
+ attribute is checked. If an error is detected, the attribute is
+ discarded, and the Error Subcode is set to Optional Attribute Error.
+ The Data field contains the attribute (type, length and value).
+
+ If any attribute appears more than once in the UPDATE message, then
+ the Error Subcode is set to Malformed Attribute List.
+
+ The NLRI field in the UPDATE message is checked for syntactic
+ validity. If the field is syntactically incorrect, then the Error
+ Subcode is set to Invalid Network Field.
+
+6.4 NOTIFICATION message error handling.
+
+ If a peer sends a NOTIFICATION message, and there is an error in that
+ message, there is unfortunately no means of reporting this error via
+ a subsequent NOTIFICATION message. Any such error, such as an
+ unrecognized Error Code or Error Subcode, should be noticed, logged
+ locally, and brought to the attention of the administration of the
+ peer. The means to do this, however, lies outside the scope of this
+ document.
+
+6.5 Hold Timer Expired error handling.
+
+ If a system does not receive successive KEEPALIVE and/or UPDATE
+ and/or NOTIFICATION messages within the period specified in the Hold
+ Time field of the OPEN message, then the NOTIFICATION message with
+ Hold Timer Expired Error Code must be sent and the BGP connection
+ closed.
+
+6.6 Finite State Machine error handling.
+
+ Any error detected by the BGP Finite State Machine (e.g., receipt of
+ an unexpected event) is indicated by sending the NOTIFICATION message
+ with Error Code Finite State Machine Error.
+
+
+
+
+
+Rekhter & Li [Page 27]
+
+RFC 1771 BGP-4 March 1995
+
+
+6.7 Cease.
+
+ In absence of any fatal errors (that are indicated in this section),
+ a BGP peer may choose at any given time to close its BGP connection
+ by sending the NOTIFICATION message with Error Code Cease. However,
+ the Cease NOTIFICATION message must not be used when a fatal error
+ indicated by this section does exist.
+
+6.8 Connection collision detection.
+
+ If a pair of BGP speakers try simultaneously to establish a TCP
+ connection to each other, then two parallel connections between this
+ pair of speakers might well be formed. We refer to this situation as
+ connection collision. Clearly, one of these connections must be
+ closed.
+
+ Based on the value of the BGP Identifier a convention is established
+ for detecting which BGP connection is to be preserved when a
+ collision does occur. The convention is to compare the BGP
+ Identifiers of the peers involved in the collision and to retain only
+ the connection initiated by the BGP speaker with the higher-valued
+ BGP Identifier.
+
+ Upon receipt of an OPEN message, the local system must examine all of
+ its connections that are in the OpenConfirm state. A BGP speaker may
+ also examine connections in an OpenSent state if it knows the BGP
+ Identifier of the peer by means outside of the protocol. If among
+ these connections there is a connection to a remote BGP speaker whose
+ BGP Identifier equals the one in the OPEN message, then the local
+ system performs the following collision resolution procedure:
+
+ 1. The BGP Identifier of the local system is compared to the BGP
+ Identifier of the remote system (as specified in the OPEN
+ message).
+
+ 2. If the value of the local BGP Identifier is less than the
+ remote one, the local system closes BGP connection that already
+ exists (the one that is already in the OpenConfirm state), and
+ accepts BGP connection initiated by the remote system.
+
+ 3. Otherwise, the local system closes newly created BGP connection
+ (the one associated with the newly received OPEN message), and
+ continues to use the existing one (the one that is already in the
+ OpenConfirm state).
+
+ Comparing BGP Identifiers is done by treating them as (4-octet
+ long) unsigned integers.
+
+
+
+
+Rekhter & Li [Page 28]
+
+RFC 1771 BGP-4 March 1995
+
+
+ A connection collision with an existing BGP connection that is in
+ Established states causes unconditional closing of the newly
+ created connection. Note that a connection collision cannot be
+ detected with connections that are in Idle, or Connect, or Active
+ states.
+
+ Closing the BGP connection (that results from the collision
+ resolution procedure) is accomplished by sending the NOTIFICATION
+ message with the Error Code Cease.
+
+7. BGP Version Negotiation.
+
+ BGP speakers may negotiate the version of the protocol by making
+ multiple attempts to open a BGP connection, starting with the highest
+ version number each supports. If an open attempt fails with an Error
+ Code OPEN Message Error, and an Error Subcode Unsupported Version
+ Number, then the BGP speaker has available the version number it
+ tried, the version number its peer tried, the version number passed
+ by its peer in the NOTIFICATION message, and the version numbers that
+ it supports. If the two peers do support one or more common
+ versions, then this will allow them to rapidly determine the highest
+ common version. In order to support BGP version negotiation, future
+ versions of BGP must retain the format of the OPEN and NOTIFICATION
+ messages.
+
+8. BGP Finite State machine.
+
+ This section specifies BGP operation in terms of a Finite State
+ Machine (FSM). Following is a brief summary and overview of BGP
+ operations by state as determined by this FSM. A condensed version
+ of the BGP FSM is found in Appendix 1.
+
+ Initially BGP is in the Idle state.
+
+ Idle state:
+
+ In this state BGP refuses all incoming BGP connections. No
+ resources are allocated to the peer. In response to the Start
+ event (initiated by either system or operator) the local system
+ initializes all BGP resources, starts the ConnectRetry timer,
+ initiates a transport connection to other BGP peer, while
+ listening for connection that may be initiated by the remote
+ BGP peer, and changes its state to Connect. The exact value of
+ the ConnectRetry timer is a local matter, but should be
+ sufficiently large to allow TCP initialization.
+
+ If a BGP speaker detects an error, it shuts down the connection
+ and changes its state to Idle. Getting out of the Idle state
+
+
+
+Rekhter & Li [Page 29]
+
+RFC 1771 BGP-4 March 1995
+
+
+ requires generation of the Start event. If such an event is
+ generated automatically, then persistent BGP errors may result
+ in persistent flapping of the speaker. To avoid such a
+ condition it is recommended that Start events should not be
+ generated immediately for a peer that was previously
+ transitioned to Idle due to an error. For a peer that was
+ previously transitioned to Idle due to an error, the time
+ between consecutive generation of Start events, if such events
+ are generated automatically, shall exponentially increase. The
+ value of the initial timer shall be 60 seconds. The time shall
+ be doubled for each consecutive retry.
+
+ Any other event received in the Idle state is ignored.
+
+ Connect state:
+
+ In this state BGP is waiting for the transport protocol
+ connection to be completed.
+
+ If the transport protocol connection succeeds, the local system
+ clears the ConnectRetry timer, completes initialization, sends
+ an OPEN message to its peer, and changes its state to OpenSent.
+
+ If the transport protocol connect fails (e.g., retransmission
+ timeout), the local system restarts the ConnectRetry timer,
+ continues to listen for a connection that may be initiated by
+ the remote BGP peer, and changes its state to Active state.
+
+ In response to the ConnectRetry timer expired event, the local
+ system restarts the ConnectRetry timer, initiates a transport
+ connection to other BGP peer, continues to listen for a
+ connection that may be initiated by the remote BGP peer, and
+ stays in the Connect state.
+
+ Start event is ignored in the Active state.
+
+ In response to any other event (initiated by either system or
+ operator), the local system releases all BGP resources
+ associated with this connection and changes its state to Idle.
+
+ Active state:
+
+ In this state BGP is trying to acquire a peer by initiating a
+ transport protocol connection.
+
+ If the transport protocol connection succeeds, the local system
+ clears the ConnectRetry timer, completes initialization, sends
+ an OPEN message to its peer, sets its Hold Timer to a large
+
+
+
+Rekhter & Li [Page 30]
+
+RFC 1771 BGP-4 March 1995
+
+
+ value, and changes its state to OpenSent. A Hold Timer value
+ of 4 minutes is suggested.
+
+ In response to the ConnectRetry timer expired event, the local
+ system restarts the ConnectRetry timer, initiates a transport
+ connection to other BGP peer, continues to listen for a
+ connection that may be initiated by the remote BGP peer, and
+ changes its state to Connect.
+
+ If the local system detects that a remote peer is trying to
+ establish BGP connection to it, and the IP address of the
+ remote peer is not an expected one, the local system restarts
+ the ConnectRetry timer, rejects the attempted connection,
+ continues to listen for a connection that may be initiated by
+ the remote BGP peer, and stays in the Active state.
+
+ Start event is ignored in the Active state.
+
+ In response to any other event (initiated by either system or
+ operator), the local system releases all BGP resources
+ associated with this connection and changes its state to Idle.
+
+ OpenSent state:
+
+ In this state BGP waits for an OPEN message from its peer.
+ When an OPEN message is received, all fields are checked for
+ correctness. If the BGP message header checking or OPEN
+ message checking detects an error (see Section 6.2), or a
+ connection collision (see Section 6.8) the local system sends a
+ NOTIFICATION message and changes its state to Idle.
+
+ If there are no errors in the OPEN message, BGP sends a
+ KEEPALIVE message and sets a KeepAlive timer. The Hold Timer,
+ which was originally set to a large value (see above), is
+ replaced with the negotiated Hold Time value (see section 4.2).
+ If the negotiated Hold Time value is zero, then the Hold Time
+ timer and KeepAlive timers are not started. If the value of
+ the Autonomous System field is the same as the local Autonomous
+ System number, then the connection is an "internal" connection;
+ otherwise, it is "external". (This will effect UPDATE
+ processing as described below.) Finally, the state is changed
+ to OpenConfirm.
+
+ If a disconnect notification is received from the underlying
+ transport protocol, the local system closes the BGP connection,
+ restarts the ConnectRetry timer, while continue listening for
+ connection that may be initiated by the remote BGP peer, and
+ goes into the Active state.
+
+
+
+Rekhter & Li [Page 31]
+
+RFC 1771 BGP-4 March 1995
+
+
+ If the Hold Timer expires, the local system sends NOTIFICATION
+ message with error code Hold Timer Expired and changes its
+ state to Idle.
+
+ In response to the Stop event (initiated by either system or
+ operator) the local system sends NOTIFICATION message with
+ Error Code Cease and changes its state to Idle.
+
+ Start event is ignored in the OpenSent state.
+
+ In response to any other event the local system sends
+ NOTIFICATION message with Error Code Finite State Machine Error
+ and changes its state to Idle.
+
+ Whenever BGP changes its state from OpenSent to Idle, it closes
+ the BGP (and transport-level) connection and releases all
+ resources associated with that connection.
+
+ OpenConfirm state:
+
+ In this state BGP waits for a KEEPALIVE or NOTIFICATION
+ message.
+
+ If the local system receives a KEEPALIVE message, it changes
+ its state to Established.
+
+ If the Hold Timer expires before a KEEPALIVE message is
+ received, the local system sends NOTIFICATION message with
+ error code Hold Timer Expired and changes its state to Idle.
+
+ If the local system receives a NOTIFICATION message, it changes
+ its state to Idle.
+
+ If the KeepAlive timer expires, the local system sends a
+ KEEPALIVE message and restarts its KeepAlive timer.
+
+ If a disconnect notification is received from the underlying
+ transport protocol, the local system changes its state to Idle.
+
+ In response to the Stop event (initiated by either system or
+ operator) the local system sends NOTIFICATION message with
+ Error Code Cease and changes its state to Idle.
+
+ Start event is ignored in the OpenConfirm state.
+
+ In response to any other event the local system sends
+ NOTIFICATION message with Error Code Finite State Machine Error
+ and changes its state to Idle.
+
+
+
+Rekhter & Li [Page 32]
+
+RFC 1771 BGP-4 March 1995
+
+
+ Whenever BGP changes its state from OpenConfirm to Idle, it
+ closes the BGP (and transport-level) connection and releases
+ all resources associated with that connection.
+
+ Established state:
+
+ In the Established state BGP can exchange UPDATE, NOTIFICATION,
+ and KEEPALIVE messages with its peer.
+
+ If the local system receives an UPDATE or KEEPALIVE message, it
+ restarts its Hold Timer, if the negotiated Hold Time value is
+ non-zero.
+
+ If the local system receives a NOTIFICATION message, it changes
+ its state to Idle.
+
+ If the local system receives an UPDATE message and the UPDATE
+ message error handling procedure (see Section 6.3) detects an
+ error, the local system sends a NOTIFICATION message and
+ changes its state to Idle.
+
+ If a disconnect notification is received from the underlying
+ transport protocol, the local system changes its state to Idle.
+
+ If the Hold Timer expires, the local system sends a
+ NOTIFICATION message with Error Code Hold Timer Expired and
+ changes its state to Idle.
+
+ If the KeepAlive timer expires, the local system sends a
+ KEEPALIVE message and restarts its KeepAlive timer.
+
+ Each time the local system sends a KEEPALIVE or UPDATE message,
+ it restarts its KeepAlive timer, unless the negotiated Hold
+ Time value is zero.
+
+ In response to the Stop event (initiated by either system or
+ operator), the local system sends a NOTIFICATION message with
+ Error Code Cease and changes its state to Idle.
+
+ Start event is ignored in the Established state.
+
+ In response to any other event, the local system sends
+ NOTIFICATION message with Error Code Finite State Machine Error
+ and changes its state to Idle.
+
+ Whenever BGP changes its state from Established to Idle, it
+ closes the BGP (and transport-level) connection, releases all
+ resources associated with that connection, and deletes all
+
+
+
+Rekhter & Li [Page 33]
+
+RFC 1771 BGP-4 March 1995
+
+
+ routes derived from that connection.
+
+9. UPDATE Message Handling
+
+ An UPDATE message may be received only in the Established state.
+ When an UPDATE message is received, each field is checked for
+ validity as specified in Section 6.3.
+
+ If an optional non-transitive attribute is unrecognized, it is
+ quietly ignored. If an optional transitive attribute is
+ unrecognized, the Partial bit (the third high-order bit) in the
+ attribute flags octet is set to 1, and the attribute is retained for
+ propagation to other BGP speakers.
+
+ If an optional attribute is recognized, and has a valid value, then,
+ depending on the type of the optional attribute, it is processed
+ locally, retained, and updated, if necessary, for possible
+ propagation to other BGP speakers.
+
+ If the UPDATE message contains a non-empty WITHDRAWN ROUTES field,
+ the previously advertised routes whose destinations (expressed as IP
+ prefixes) contained in this field shall be removed from the Adj-RIB-
+ In. This BGP speaker shall run its Decision Process since the
+ previously advertised route is not longer available for use.
+
+ If the UPDATE message contains a feasible route, it shall be placed
+ in the appropriate Adj-RIB-In, and the following additional actions
+ shall be taken:
+
+ i) If its Network Layer Reachability Information (NLRI) is identical
+ to the one of a route currently stored in the Adj-RIB-In, then the
+ new route shall replace the older route in the Adj-RIB-In, thus
+ implicitly withdrawing the older route from service. The BGP speaker
+ shall run its Decision Process since the older route is no longer
+ available for use.
+
+ ii) If the new route is an overlapping route that is included (see
+ 9.1.4) in an earlier route contained in the Adj-RIB-In, the BGP
+ speaker shall run its Decision Process since the more specific route
+ has implicitly made a portion of the less specific route unavailable
+ for use.
+
+ iii) If the new route has identical path attributes to an earlier
+ route contained in the Adj-RIB-In, and is more specific (see 9.1.4)
+ than the earlier route, no further actions are necessary.
+
+ iv) If the new route has NLRI that is not present in any of the
+ routes currently stored in the Adj-RIB-In, then the new route shall
+
+
+
+Rekhter & Li [Page 34]
+
+RFC 1771 BGP-4 March 1995
+
+
+ be placed in the Adj-RIB-In. The BGP speaker shall run its Decision
+ Process.
+
+ v) If the new route is an overlapping route that is less specific
+ (see 9.1.4) than an earlier route contained in the Adj-RIB-In, the
+ BGP speaker shall run its Decision Process on the set of destinations
+ described only by the less specific route.
+
+9.1 Decision Process
+
+ The Decision Process selects routes for subsequent advertisement by
+ applying the policies in the local Policy Information Base (PIB) to
+ the routes stored in its Adj-RIB-In. The output of the Decision
+ Process is the set of routes that will be advertised to all peers;
+ the selected routes will be stored in the local speaker's Adj-RIB-
+ Out.
+
+ The selection process is formalized by defining a function that takes
+ the attribute of a given route as an argument and returns a non-
+ negative integer denoting the degree of preference for the route.
+ The function that calculates the degree of preference for a given
+ route shall not use as its inputs any of the following: the
+ existence of other routes, the non-existence of other routes, or the
+ path attributes of other routes. Route selection then consists of
+ individual application of the degree of preference function to each
+ feasible route, followed by the choice of the one with the highest
+ degree of preference.
+
+ The Decision Process operates on routes contained in each Adj-RIB-In,
+ and is responsible for:
+
+ - selection of routes to be advertised to BGP speakers located in
+ the local speaker's autonomous system
+
+ - selection of routes to be advertised to BGP speakers located in
+ neighboring autonomous systems
+
+ - route aggregation and route information reduction
+
+ The Decision Process takes place in three distinct phases, each
+ triggered by a different event:
+
+ a) Phase 1 is responsible for calculating the degree of preference
+ for each route received from a BGP speaker located in a
+ neighboring autonomous system, and for advertising to the other
+ BGP speakers in the local autonomous system the routes that have
+ the highest degree of preference for each distinct destination.
+
+
+
+
+Rekhter & Li [Page 35]
+
+RFC 1771 BGP-4 March 1995
+
+
+ b) Phase 2 is invoked on completion of phase 1. It is responsible
+ for choosing the best route out of all those available for each
+ distinct destination, and for installing each chosen route into
+ the appropriate Loc-RIB.
+
+ c) Phase 3 is invoked after the Loc-RIB has been modified. It is
+ responsible for disseminating routes in the Loc-RIB to each peer
+ located in a neighboring autonomous system, according to the
+ policies contained in the PIB. Route aggregation and information
+ reduction can optionally be performed within this phase.
+
+9.1.1 Phase 1: Calculation of Degree of Preference
+
+ The Phase 1 decision function shall be invoked whenever the local BGP
+ speaker receives an UPDATE message from a peer located in a
+ neighboring autonomous system that advertises a new route, a
+ replacement route, or a withdrawn route.
+
+ The Phase 1 decision function is a separate process which completes
+ when it has no further work to do.
+
+ The Phase 1 decision function shall lock an Adj-RIB-In prior to
+ operating on any route contained within it, and shall unlock it after
+ operating on all new or unfeasible routes contained within it.
+
+ For each newly received or replacement feasible route, the local BGP
+ speaker shall determine a degree of preference. If the route is
+ learned from a BGP speaker in the local autonomous system, either the
+ value of the LOCAL_PREF attribute shall be taken as the degree of
+ preference, or the local system shall compute the degree of
+ preference of the route based on preconfigured policy information. If
+ the route is learned from a BGP speaker in a neighboring autonomous
+ system, then the degree of preference shall be computed based on
+ preconfigured policy information. The exact nature of this policy
+ information and the computation involved is a local matter. The
+ local speaker shall then run the internal update process of 9.2.1 to
+ select and advertise the most preferable route.
+
+9.1.2 Phase 2: Route Selection
+
+ The Phase 2 decision function shall be invoked on completion of Phase
+ 1. The Phase 2 function is a separate process which completes when
+ it has no further work to do. The Phase 2 process shall consider all
+ routes that are present in the Adj-RIBs-In, including those received
+ from BGP speakers located in its own autonomous system and those
+ received from BGP speakers located in neighboring autonomous systems.
+
+
+
+
+
+Rekhter & Li [Page 36]
+
+RFC 1771 BGP-4 March 1995
+
+
+ The Phase 2 decision function shall be blocked from running while the
+ Phase 3 decision function is in process. The Phase 2 function shall
+ lock all Adj-RIBs-In prior to commencing its function, and shall
+ unlock them on completion.
+
+ If the NEXT_HOP attribute of a BGP route depicts an address to which
+ the local BGP speaker doesn't have a route in its Loc-RIB, the BGP
+ route SHOULD be excluded from the Phase 2 decision function.
+
+ For each set of destinations for which a feasible route exists in the
+ Adj-RIBs-In, the local BGP speaker shall identify the route that has:
+
+ a) the highest degree of preference of any route to the same set
+ of destinations, or
+
+ b) is the only route to that destination, or
+
+ c) is selected as a result of the Phase 2 tie breaking rules
+ specified in 9.1.2.1.
+
+ The local speaker SHALL then install that route in the Loc-RIB,
+ replacing any route to the same destination that is currently being
+ held in the Loc-RIB. The local speaker MUST determine the immediate
+ next hop to the address depicted by the NEXT_HOP attribute of the
+ selected route by performing a lookup in the IGP and selecting one of
+ the possible paths in the IGP. This immediate next hop MUST be used
+ when installing the selected route in the Loc-RIB. If the route to
+ the address depicted by the NEXT_HOP attribute changes such that the
+ immediate next hop changes, route selection should be recalculated as
+ specified above.
+
+ Unfeasible routes shall be removed from the Loc-RIB, and
+ corresponding unfeasible routes shall then be removed from the Adj-
+ RIBs-In.
+
+9.1.2.1 Breaking Ties (Phase 2)
+
+ In its Adj-RIBs-In a BGP speaker may have several routes to the same
+ destination that have the same degree of preference. The local
+ speaker can select only one of these routes for inclusion in the
+ associated Loc-RIB. The local speaker considers all equally
+ preferable routes, both those received from BGP speakers located in
+ neighboring autonomous systems, and those received from other BGP
+ speakers located in the local speaker's autonomous system.
+
+ The following tie-breaking procedure assumes that for each candidate
+ route all the BGP speakers within an autonomous system can ascertain
+ the cost of a path (interior distance) to the address depicted by the
+
+
+
+Rekhter & Li [Page 37]
+
+RFC 1771 BGP-4 March 1995
+
+
+ NEXT_HOP attribute of the route. Ties shall be broken according to
+ the following algorithm:
+
+ a) If the local system is configured to take into account
+ MULTI_EXIT_DISC, and the candidate routes differ in their
+ MULTI_EXIT_DISC attribute, select the route that has the lowest
+ value of the MULTI_EXIT_DISC attribute.
+
+ b) Otherwise, select the route that has the lowest cost (interior
+ distance) to the entity depicted by the NEXT_HOP attribute of the
+ route. If there are several routes with the same cost, then the
+ tie-breaking shall be broken as follows:
+
+ - if at least one of the candidate routes was advertised by the
+ BGP speaker in a neighboring autonomous system, select the
+ route that was advertised by the BGP speaker in a neighboring
+ autonomous system whose BGP Identifier has the lowest value
+ among all other BGP speakers in neighboring autonomous systems;
+
+ - otherwise, select the route that was advertised by the BGP
+ speaker whose BGP Identifier has the lowest value.
+
+9.1.3 Phase 3: Route Dissemination
+
+ The Phase 3 decision function shall be invoked on completion of Phase
+ 2, or when any of the following events occur:
+
+ a) when routes in a Loc-RIB to local destinations have changed
+
+ b) when locally generated routes learned by means outside of BGP
+ have changed
+
+ c) when a new BGP speaker - BGP speaker connection has been
+ established
+
+ The Phase 3 function is a separate process which completes when it
+ has no further work to do. The Phase 3 Routing Decision function
+ shall be blocked from running while the Phase 2 decision function is
+ in process.
+
+ All routes in the Loc-RIB shall be processed into a corresponding
+ entry in the associated Adj-RIBs-Out. Route aggregation and
+ information reduction techniques (see 9.2.4.1) may optionally be
+ applied.
+
+ For the benefit of future support of inter-AS multicast capabilities,
+ a BGP speaker that participates in inter-AS multicast routing shall
+ advertise a route it receives from one of its external peers and if
+
+
+
+Rekhter & Li [Page 38]
+
+RFC 1771 BGP-4 March 1995
+
+
+ it installs it in its Loc-RIB, it shall advertise it back to the peer
+ from which the route was received. For a BGP speaker that does not
+ participate in inter-AS multicast routing such an advertisement is
+ optional. When doing such an advertisement, the NEXT_HOP attribute
+ should be set to the address of the peer. An implementation may also
+ optimize such an advertisement by truncating information in the
+ AS_PATH attribute to include only its own AS number and that of the
+ peer that advertised the route (such truncation requires the ORIGIN
+ attribute to be set to INCOMPLETE). In addition an implementation is
+ not required to pass optional or discretionary path attributes with
+ such an advertisement.
+
+ When the updating of the Adj-RIBs-Out and the Forwarding Information
+ Base (FIB) is complete, the local BGP speaker shall run the external
+ update process of 9.2.2.
+
+9.1.4 Overlapping Routes
+
+ A BGP speaker may transmit routes with overlapping Network Layer
+ Reachability Information (NLRI) to another BGP speaker. NLRI overlap
+ occurs when a set of destinations are identified in non-matching
+ multiple routes. Since BGP encodes NLRI using IP prefixes, overlap
+ will always exhibit subset relationships. A route describing a
+ smaller set of destinations (a longer prefix) is said to be more
+ specific than a route describing a larger set of destinations (a
+ shorted prefix); similarly, a route describing a larger set of
+ destinations (a shorter prefix) is said to be less specific than a
+ route describing a smaller set of destinations (a longer prefix).
+
+ The precedence relationship effectively decomposes less specific
+ routes into two parts:
+
+ - a set of destinations described only by the less specific
+ route, and
+
+ - a set of destinations described by the overlap of the less
+ specific and the more specific routes
+
+ When overlapping routes are present in the same Adj-RIB-In, the more
+ specific route shall take precedence, in order from more specific to
+ least specific.
+
+ The set of destinations described by the overlap represents a portion
+ of the less specific route that is feasible, but is not currently in
+ use. If a more specific route is later withdrawn, the set of
+ destinations described by the overlap will still be reachable using
+ the less specific route.
+
+
+
+
+Rekhter & Li [Page 39]
+
+RFC 1771 BGP-4 March 1995
+
+
+ If a BGP speaker receives overlapping routes, the Decision Process
+ shall take into account the semantics of the overlapping routes. In
+ particular, if a BGP speaker accepts the less specific route while
+ rejecting the more specific route from the same peer, then the
+ destinations represented by the overlap may not forward along the ASs
+ listed in the AS_PATH attribute of that route. Therefore, a BGP
+ speaker has the following choices:
+
+ a) Install both the less and the more specific routes
+
+ b) Install the more specific route only
+
+ c) Install the non-overlapping part of the less specific
+ route only (that implies de-aggregation)
+
+ d) Aggregate the two routes and install the aggregated route
+
+ e) Install the less specific route only
+
+ f) Install neither route
+
+ If a BGP speaker chooses e), then it should add ATOMIC_AGGREGATE
+ attribute to the route. A route that carries ATOMIC_AGGREGATE
+ attribute can not be de-aggregated. That is, the NLRI of this route
+ can not be made more specific. Forwarding along such a route does
+ not guarantee that IP packets will actually traverse only ASs listed
+ in the AS_PATH attribute of the route. If a BGP speaker chooses a),
+ it must not advertise the more general route without the more
+ specific route.
+
+9.2 Update-Send Process
+
+ The Update-Send process is responsible for advertising UPDATE
+ messages to all peers. For example, it distributes the routes chosen
+ by the Decision Process to other BGP speakers which may be located in
+ either the same autonomous system or a neighboring autonomous system.
+ rules for information exchange between BGP speakers located in
+ different autonomous systems are given in 9.2.2; rules for
+ information exchange between BGP speakers located in the same
+ autonomous system are given in 9.2.1.
+
+ Distribution of routing information between a set of BGP speakers,
+ all of which are located in the same autonomous system, is referred
+ to as internal distribution.
+
+
+
+
+
+
+
+Rekhter & Li [Page 40]
+
+RFC 1771 BGP-4 March 1995
+
+
+9.2.1 Internal Updates
+
+ The Internal update process is concerned with the distribution of
+ routing information to BGP speakers located in the local speaker's
+ autonomous system.
+
+ When a BGP speaker receives an UPDATE message from another BGP
+ speaker located in its own autonomous system, the receiving BGP
+ speaker shall not re-distribute the routing information contained in
+ that UPDATE message to other BGP speakers located in its own
+ autonomous system.
+
+ When a BGP speaker receives a new route from a BGP speaker in a
+ neighboring autonomous system, it shall advertise that route to all
+ other BGP speakers in its autonomous system by means of an UPDATE
+ message if any of the following conditions occur:
+
+ 1) the degree of preference assigned to the newly received route
+ by the local BGP speaker is higher than the degree of preference
+ that the local speaker has assigned to other routes that have been
+ received from BGP speakers in neighboring autonomous systems, or
+
+ 2) there are no other routes that have been received from BGP
+ speakers in neighboring autonomous systems, or
+
+ 3) the newly received route is selected as a result of breaking a
+ tie between several routes which have the highest degree of
+ preference, and the same destination (the tie-breaking procedure
+ is specified in 9.2.1.1).
+
+ When a BGP speaker receives an UPDATE message with a non-empty
+ WITHDRAWN ROUTES field, it shall remove from its Adj-RIB-In all
+ routes whose destinations was carried in this field (as IP prefixes).
+ The speaker shall take the following additional steps:
+
+ 1) if the corresponding feasible route had not been previously
+ advertised, then no further action is necessary
+
+ 2) if the corresponding feasible route had been previously
+ advertised, then:
+
+ i) if a new route is selected for advertisement that has the
+ same Network Layer Reachability Information as the unfeasible
+ routes, then the local BGP speaker shall advertise the
+ replacement route
+
+ ii) if a replacement route is not available for advertisement,
+ then the BGP speaker shall include the destinations of the
+
+
+
+Rekhter & Li [Page 41]
+
+RFC 1771 BGP-4 March 1995
+
+
+ unfeasible route (in form of IP prefixes) in the WITHDRAWN
+ ROUTES field of an UPDATE message, and shall send this message
+ to each peer to whom it had previously advertised the
+ corresponding feasible route.
+
+ All feasible routes which are advertised shall be placed in the
+ appropriate Adj-RIBs-Out, and all unfeasible routes which are
+ advertised shall be removed from the Adj-RIBs-Out.
+
+9.2.1.1 Breaking Ties (Internal Updates)
+
+ If a local BGP speaker has connections to several BGP speakers in
+ neighboring autonomous systems, there will be multiple Adj-RIBs-In
+ associated with these peers. These Adj-RIBs-In might contain several
+ equally preferable routes to the same destination, all of which were
+ advertised by BGP speakers located in neighboring autonomous systems.
+ The local BGP speaker shall select one of these routes according to
+ the following rules:
+
+ a) If the candidate route differ only in their NEXT_HOP and
+ MULTI_EXIT_DISC attributes, and the local system is configured to
+ take into account MULTI_EXIT_DISC attribute, select the routes
+ that has the lowest value of the MULTI_EXIT_DISC attribute.
+
+ b) If the local system can ascertain the cost of a path to the
+ entity depicted by the NEXT_HOP attribute of the candidate route,
+ select the route with the lowest cost.
+
+ c) In all other cases, select the route that was advertised by the
+ BGP speaker whose BGP Identifier has the lowest value.
+
+9.2.2 External Updates
+
+ The external update process is concerned with the distribution of
+ routing information to BGP speakers located in neighboring autonomous
+ systems. As part of Phase 3 route selection process, the BGP speaker
+ has updated its Adj-RIBs-Out and its Forwarding Table. All newly
+ installed routes and all newly unfeasible routes for which there is
+ no replacement route shall be advertised to BGP speakers located in
+ neighboring autonomous systems by means of UPDATE message.
+
+ Any routes in the Loc-RIB marked as unfeasible shall be removed.
+ Changes to the reachable destinations within its own autonomous
+ system shall also be advertised in an UPDATE message.
+
+
+
+
+
+
+
+Rekhter & Li [Page 42]
+
+RFC 1771 BGP-4 March 1995
+
+
+9.2.3 Controlling Routing Traffic Overhead
+
+ The BGP protocol constrains the amount of routing traffic (that is,
+ UPDATE messages) in order to limit both the link bandwidth needed to
+ advertise UPDATE messages and the processing power needed by the
+ Decision Process to digest the information contained in the UPDATE
+ messages.
+
+9.2.3.1 Frequency of Route Advertisement
+
+ The parameter MinRouteAdvertisementInterval determines the minimum
+ amount of time that must elapse between advertisement of routes to a
+ particular destination from a single BGP speaker. This rate limiting
+ procedure applies on a per-destination basis, although the value of
+ MinRouteAdvertisementInterval is set on a per BGP peer basis.
+
+ Two UPDATE messages sent from a single BGP speaker that advertise
+ feasible routes to some common set of destinations received from BGP
+ speakers in neighboring autonomous systems must be separated by at
+ least MinRouteAdvertisementInterval. Clearly, this can only be
+ achieved precisely by keeping a separate timer for each common set of
+ destinations. This would be unwarranted overhead. Any technique which
+ ensures that the interval between two UPDATE messages sent from a
+ single BGP speaker that advertise feasible routes to some common set
+ of destinations received from BGP speakers in neighboring autonomous
+ systems will be at least MinRouteAdvertisementInterval, and will also
+ ensure a constant upper bound on the interval is acceptable.
+
+ Since fast convergence is needed within an autonomous system, this
+ procedure does not apply for routes receives from other BGP speakers
+ in the same autonomous system. To avoid long-lived black holes, the
+ procedure does not apply to the explicit withdrawal of unfeasible
+ routes (that is, routes whose destinations (expressed as IP prefixes)
+ are listed in the WITHDRAWN ROUTES field of an UPDATE message).
+
+ This procedure does not limit the rate of route selection, but only
+ the rate of route advertisement. If new routes are selected multiple
+ times while awaiting the expiration of MinRouteAdvertisementInterval,
+ the last route selected shall be advertised at the end of
+ MinRouteAdvertisementInterval.
+
+9.2.3.2 Frequency of Route Origination
+
+ The parameter MinASOriginationInterval determines the minimum amount
+ of time that must elapse between successive advertisements of UPDATE
+ messages that report changes within the advertising BGP speaker's own
+ autonomous systems.
+
+
+
+
+Rekhter & Li [Page 43]
+
+RFC 1771 BGP-4 March 1995
+
+
+9.2.3.3 Jitter
+
+ To minimize the likelihood that the distribution of BGP messages by a
+ given BGP speaker will contain peaks, jitter should be applied to the
+ timers associated with MinASOriginationInterval, Keepalive, and
+ MinRouteAdvertisementInterval. A given BGP speaker shall apply the
+ same jitter to each of these quantities regardless of the
+ destinations to which the updates are being sent; that is, jitter
+ will not be applied on a "per peer" basis.
+
+ The amount of jitter to be introduced shall be determined by
+ multiplying the base value of the appropriate timer by a random
+ factor which is uniformly distributed in the range from 0.75 to 1.0.
+
+9.2.4 Efficient Organization of Routing Information
+
+ Having selected the routing information which it will advertise, a
+ BGP speaker may avail itself of several methods to organize this
+ information in an efficient manner.
+
+9.2.4.1 Information Reduction
+
+ Information reduction may imply a reduction in granularity of policy
+ control - after information is collapsed, the same policies will
+ apply to all destinations and paths in the equivalence class.
+
+ The Decision Process may optionally reduce the amount of information
+ that it will place in the Adj-RIBs-Out by any of the following
+ methods:
+
+ a) Network Layer Reachability Information (NLRI):
+
+ Destination IP addresses can be represented as IP address
+ prefixes. In cases where there is a correspondence between the
+ address structure and the systems under control of an autonomous
+ system administrator, it will be possible to reduce the size of
+ the NLRI carried in the UPDATE messages.
+
+ b) AS_PATHs:
+
+ AS path information can be represented as ordered AS_SEQUENCEs or
+ unordered AS_SETs. AS_SETs are used in the route aggregation
+ algorithm described in 9.2.4.2. They reduce the size of the
+ AS_PATH information by listing each AS number only once,
+ regardless of how many times it may have appeared in multiple
+ AS_PATHs that were aggregated.
+
+
+
+
+
+Rekhter & Li [Page 44]
+
+RFC 1771 BGP-4 March 1995
+
+
+ An AS_SET implies that the destinations listed in the NLRI can be
+ reached through paths that traverse at least some of the
+ constituent autonomous systems. AS_SETs provide sufficient
+ information to avoid routing information looping; however their
+ use may prune potentially feasible paths, since such paths are no
+ longer listed individually as in the form of AS_SEQUENCEs. In
+ practice this is not likely to be a problem, since once an IP
+ packet arrives at the edge of a group of autonomous systems, the
+ BGP speaker at that point is likely to have more detailed path
+ information and can distinguish individual paths to destinations.
+
+9.2.4.2 Aggregating Routing Information
+
+ Aggregation is the process of combining the characteristics of
+ several different routes in such a way that a single route can be
+ advertised. Aggregation can occur as part of the decision process
+ to reduce the amount of routing information that will be placed in
+ the Adj-RIBs-Out.
+
+ Aggregation reduces the amount of information that a BGP speaker must
+ store and exchange with other BGP speakers. Routes can be aggregated
+ by applying the following procedure separately to path attributes of
+ like type and to the Network Layer Reachability Information.
+
+ Routes that have the following attributes shall not be aggregated
+ unless the corresponding attributes of each route are identical:
+ MULTI_EXIT_DISC, NEXT_HOP.
+
+ Path attributes that have different type codes can not be aggregated
+ together. Path of the same type code may be aggregated, according to
+ the following rules:
+
+ ORIGIN attribute: If at least one route among routes that are
+ aggregated has ORIGIN with the value INCOMPLETE, then the
+ aggregated route must have the ORIGIN attribute with the value
+ INCOMPLETE. Otherwise, if at least one route among routes that are
+ aggregated has ORIGIN with the value EGP, then the aggregated
+ route must have the origin attribute with the value EGP. In all
+ other case the value of the ORIGIN attribute of the aggregated
+ route is INTERNAL.
+
+ AS_PATH attribute: If routes to be aggregated have identical
+ AS_PATH attributes, then the aggregated route has the same AS_PATH
+ attribute as each individual route.
+
+ For the purpose of aggregating AS_PATH attributes we model each AS
+ within the AS_PATH attribute as a tuple <type, value>, where
+ "type" identifies a type of the path segment the AS belongs to
+
+
+
+Rekhter & Li [Page 45]
+
+RFC 1771 BGP-4 March 1995
+
+
+ (e.g. AS_SEQUENCE, AS_SET), and "value" is the AS number. If the
+ routes to be aggregated have different AS_PATH attributes, then
+ the aggregated AS_PATH attribute shall satisfy all of the
+ following conditions:
+
+ - all tuples of the type AS_SEQUENCE in the aggregated AS_PATH
+ shall appear in all of the AS_PATH in the initial set of routes
+ to be aggregated.
+
+ - all tuples of the type AS_SET in the aggregated AS_PATH shall
+ appear in at least one of the AS_PATH in the initial set (they
+ may appear as either AS_SET or AS_SEQUENCE types).
+
+ - for any tuple X of the type AS_SEQUENCE in the aggregated
+ AS_PATH which precedes tuple Y in the aggregated AS_PATH, X
+ precedes Y in each AS_PATH in the initial set which contains Y,
+ regardless of the type of Y.
+
+ - No tuple with the same value shall appear more than once in
+ the aggregated AS_PATH, regardless of the tuple's type.
+
+ An implementation may choose any algorithm which conforms to these
+ rules. At a minimum a conformant implementation shall be able to
+ perform the following algorithm that meets all of the above
+ conditions:
+
+ - determine the longest leading sequence of tuples (as defined
+ above) common to all the AS_PATH attributes of the routes to be
+ aggregated. Make this sequence the leading sequence of the
+ aggregated AS_PATH attribute.
+
+ - set the type of the rest of the tuples from the AS_PATH
+ attributes of the routes to be aggregated to AS_SET, and append
+ them to the aggregated AS_PATH attribute.
+
+ - if the aggregated AS_PATH has more than one tuple with the
+ same value (regardless of tuple's type), eliminate all, but one
+ such tuple by deleting tuples of the type AS_SET from the
+ aggregated AS_PATH attribute.
+
+ Appendix 6, section 6.8 presents another algorithm that satisfies
+ the conditions and allows for more complex policy configurations.
+
+ ATOMIC_AGGREGATE: If at least one of the routes to be aggregated
+ has ATOMIC_AGGREGATE path attribute, then the aggregated route
+ shall have this attribute as well.
+
+
+
+
+
+Rekhter & Li [Page 46]
+
+RFC 1771 BGP-4 March 1995
+
+
+ AGGREGATOR: All AGGREGATOR attributes of all routes to be
+ aggregated should be ignored.
+
+9.3 Route Selection Criteria
+
+ Generally speaking, additional rules for comparing routes among
+ several alternatives are outside the scope of this document. There
+ are two exceptions:
+
+ - If the local AS appears in the AS path of the new route being
+ considered, then that new route cannot be viewed as better than
+ any other route. If such a route were ever used, a routing loop
+ would result.
+
+ - In order to achieve successful distributed operation, only
+ routes with a likelihood of stability can be chosen. Thus, an AS
+ must avoid using unstable routes, and it must not make rapid
+ spontaneous changes to its choice of route. Quantifying the terms
+ "unstable" and "rapid" in the previous sentence will require
+ experience, but the principle is clear.
+
+9.4 Originating BGP routes
+
+ A BGP speaker may originate BGP routes by injecting routing
+ information acquired by some other means (e.g. via an IGP) into BGP.
+ A BGP speaker that originates BGP routes shall assign the degree of
+ preference to these routes by passing them through the Decision
+ Process (see Section 9.1). These routes may also be distributed to
+ other BGP speakers within the local AS as part of the Internal update
+ process (see Section 9.2.1). The decision whether to distribute non-
+ BGP acquired routes within an AS via BGP or not depends on the
+ environment within the AS (e.g. type of IGP) and should be controlled
+ via configuration.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rekhter & Li [Page 47]
+
+RFC 1771 BGP-4 March 1995
+
+
+Appendix 1. BGP FSM State Transitions and Actions.
+
+ This Appendix discusses the transitions between states in the BGP FSM
+ in response to BGP events. The following is the list of these states
+ and events when the negotiated Hold Time value is non-zero.
+
+ BGP States:
+
+ 1 - Idle
+ 2 - Connect
+ 3 - Active
+ 4 - OpenSent
+ 5 - OpenConfirm
+ 6 - Established
+
+ BGP Events:
+
+ 1 - BGP Start
+ 2 - BGP Stop
+ 3 - BGP Transport connection open
+ 4 - BGP Transport connection closed
+ 5 - BGP Transport connection open failed
+ 6 - BGP Transport fatal error
+ 7 - ConnectRetry timer expired
+ 8 - Hold Timer expired
+ 9 - KeepAlive timer expired
+ 10 - Receive OPEN message
+ 11 - Receive KEEPALIVE message
+ 12 - Receive UPDATE messages
+ 13 - Receive NOTIFICATION message
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rekhter & Li [Page 48]
+
+RFC 1771 BGP-4 March 1995
+
+
+ The following table describes the state transitions of the BGP FSM
+ and the actions triggered by these transitions.
+
+
+ Event Actions Message Sent Next State
+ --------------------------------------------------------------------
+ Idle (1)
+ 1 Initialize resources none 2
+ Start ConnectRetry timer
+ Initiate a transport connection
+ others none none 1
+
+ Connect(2)
+ 1 none none 2
+ 3 Complete initialization OPEN 4
+ Clear ConnectRetry timer
+ 5 Restart ConnectRetry timer none 3
+ 7 Restart ConnectRetry timer none 2
+ Initiate a transport connection
+ others Release resources none 1
+
+ Active (3)
+ 1 none none 3
+ 3 Complete initialization OPEN 4
+ Clear ConnectRetry timer
+ 5 Close connection 3
+ Restart ConnectRetry timer
+ 7 Restart ConnectRetry timer none 2
+ Initiate a transport connection
+ others Release resources none 1
+
+ OpenSent(4)
+ 1 none none 4
+ 4 Close transport connection none 3
+ Restart ConnectRetry timer
+ 6 Release resources none 1
+ 10 Process OPEN is OK KEEPALIVE 5
+ Process OPEN failed NOTIFICATION 1
+ others Close transport connection NOTIFICATION 1
+ Release resources
+
+
+
+
+
+
+
+
+
+
+
+Rekhter & Li [Page 49]
+
+RFC 1771 BGP-4 March 1995
+
+
+ OpenConfirm (5)
+ 1 none none 5
+ 4 Release resources none 1
+ 6 Release resources none 1
+ 9 Restart KeepAlive timer KEEPALIVE 5
+ 11 Complete initialization none 6
+ Restart Hold Timer
+ 13 Close transport connection 1
+ Release resources
+ others Close transport connection NOTIFICATION 1
+ Release resources
+
+ Established (6)
+ 1 none none 6
+ 4 Release resources none 1
+ 6 Release resources none 1
+ 9 Restart KeepAlive timer KEEPALIVE 6
+ 11 Restart Hold Timer KEEPALIVE 6
+ 12 Process UPDATE is OK UPDATE 6
+ Process UPDATE failed NOTIFICATION 1
+ 13 Close transport connection 1
+ Release resources
+ others Close transport connection NOTIFICATION 1
+ Release resources
+ ---------------------------------------------------------------------
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rekhter & Li [Page 50]
+
+RFC 1771 BGP-4 March 1995
+
+
+ The following is a condensed version of the above state transition
+ table.
+
+
+ Events| Idle | Connect | Active | OpenSent | OpenConfirm | Estab
+ | (1) | (2) | (3) | (4) | (5) | (6)
+ |--------------------------------------------------------------
+ 1 | 2 | 2 | 3 | 4 | 5 | 6
+ | | | | | |
+ 2 | 1 | 1 | 1 | 1 | 1 | 1
+ | | | | | |
+ 3 | 1 | 4 | 4 | 1 | 1 | 1
+ | | | | | |
+ 4 | 1 | 1 | 1 | 3 | 1 | 1
+ | | | | | |
+ 5 | 1 | 3 | 3 | 1 | 1 | 1
+ | | | | | |
+ 6 | 1 | 1 | 1 | 1 | 1 | 1
+ | | | | | |
+ 7 | 1 | 2 | 2 | 1 | 1 | 1
+ | | | | | |
+ 8 | 1 | 1 | 1 | 1 | 1 | 1
+ | | | | | |
+ 9 | 1 | 1 | 1 | 1 | 5 | 6
+ | | | | | |
+ 10 | 1 | 1 | 1 | 1 or 5 | 1 | 1
+ | | | | | |
+ 11 | 1 | 1 | 1 | 1 | 6 | 6
+ | | | | | |
+ 12 | 1 | 1 | 1 | 1 | 1 | 1 or 6
+ | | | | | |
+ 13 | 1 | 1 | 1 | 1 | 1 | 1
+ | | | | | |
+ ---------------------------------------------------------------
+
+
+Appendix 2. Comparison with RFC1267
+
+ BGP-4 is capable of operating in an environment where a set of
+ reachable destinations may be expressed via a single IP prefix. The
+ concept of network classes, or subnetting is foreign to BGP-4. To
+ accommodate these capabilities BGP-4 changes semantics and encoding
+ associated with the AS_PATH attribute. New text has been added to
+ define semantics associated with IP prefixes. These abilities allow
+ BGP-4 to support the proposed supernetting scheme [9].
+
+ To simplify configuration this version introduces a new attribute,
+ LOCAL_PREF, that facilitates route selection procedures.
+
+
+
+Rekhter & Li [Page 51]
+
+RFC 1771 BGP-4 March 1995
+
+
+ The INTER_AS_METRIC attribute has been renamed to be MULTI_EXIT_DISC.
+ A new attribute, ATOMIC_AGGREGATE, has been introduced to insure that
+ certain aggregates are not de-aggregated. Another new attribute,
+ AGGREGATOR, can be added to aggregate routes in order to advertise
+ which AS and which BGP speaker within that AS caused the aggregation.
+
+ To insure that Hold Timers are symmetric, the Hold Time is now
+ negotiated on a per-connection basis. Hold Times of zero are now
+ supported.
+
+Appendix 3. Comparison with RFC 1163
+
+ All of the changes listed in Appendix 2, plus the following.
+
+ To detect and recover from BGP connection collision, a new field (BGP
+ Identifier) has been added to the OPEN message. New text (Section
+ 6.8) has been added to specify the procedure for detecting and
+ recovering from collision.
+
+ The new document no longer restricts the border router that is passed
+ in the NEXT_HOP path attribute to be part of the same Autonomous
+ System as the BGP Speaker.
+
+ New document optimizes and simplifies the exchange of the information
+ about previously reachable routes.
+
+Appendix 4. Comparison with RFC 1105
+
+ All of the changes listed in Appendices 2 and 3, plus the following.
+
+ Minor changes to the RFC1105 Finite State Machine were necessary to
+ accommodate the TCP user interface provided by 4.3 BSD.
+
+ The notion of Up/Down/Horizontal relations present in RFC1105 has
+ been removed from the protocol.
+
+ The changes in the message format from RFC1105 are as follows:
+
+ 1. The Hold Time field has been removed from the BGP header and
+ added to the OPEN message.
+
+ 2. The version field has been removed from the BGP header and
+ added to the OPEN message.
+
+ 3. The Link Type field has been removed from the OPEN message.
+
+ 4. The OPEN CONFIRM message has been eliminated and replaced with
+ implicit confirmation provided by the KEEPALIVE message.
+
+
+
+Rekhter & Li [Page 52]
+
+RFC 1771 BGP-4 March 1995
+
+
+ 5. The format of the UPDATE message has been changed
+ significantly. New fields were added to the UPDATE message to
+ support multiple path attributes.
+
+ 6. The Marker field has been expanded and its role broadened to
+ support authentication.
+
+ Note that quite often BGP, as specified in RFC 1105, is referred
+ to as BGP-1, BGP, as specified in RFC 1163, is referred to as
+ BGP-2, BGP, as specified in RFC1267 is referred to as BGP-3, and
+ BGP, as specified in this document is referred to as BGP-4.
+
+Appendix 5. TCP options that may be used with BGP
+
+ If a local system TCP user interface supports TCP PUSH function, then
+ each BGP message should be transmitted with PUSH flag set. Setting
+ PUSH flag forces BGP messages to be transmitted promptly to the
+ receiver.
+
+ If a local system TCP user interface supports setting precedence for
+ TCP connection, then the BGP transport connection should be opened
+ with precedence set to Internetwork Control (110) value (see also
+ [6]).
+
+Appendix 6. Implementation Recommendations
+
+ This section presents some implementation recommendations.
+
+6.1 Multiple Networks Per Message
+
+ The BGP protocol allows for multiple address prefixes with the same
+ AS path and next-hop gateway to be specified in one message. Making
+ use of this capability is highly recommended. With one address prefix
+ per message there is a substantial increase in overhead in the
+ receiver. Not only does the system overhead increase due to the
+ reception of multiple messages, but the overhead of scanning the
+ routing table for updates to BGP peers and other routing protocols
+ (and sending the associated messages) is incurred multiple times as
+ well. One method of building messages containing many address
+ prefixes per AS path and gateway from a routing table that is not
+ organized per AS path is to build many messages as the routing table
+ is scanned. As each address prefix is processed, a message for the
+ associated AS path and gateway is allocated, if it does not exist,
+ and the new address prefix is added to it. If such a message exists,
+ the new address prefix is just appended to it. If the message lacks
+ the space to hold the new address prefix, it is transmitted, a new
+ message is allocated, and the new address prefix is inserted into the
+ new message. When the entire routing table has been scanned, all
+
+
+
+Rekhter & Li [Page 53]
+
+RFC 1771 BGP-4 March 1995
+
+
+ allocated messages are sent and their resources released. Maximum
+ compression is achieved when all the destinations covered by the
+ address prefixes share a gateway and common path attributes, making
+ it possible to send many address prefixes in one 4096-byte message.
+
+ When peering with a BGP implementation that does not compress
+ multiple address prefixes into one message, it may be necessary to
+ take steps to reduce the overhead from the flood of data received
+ when a peer is acquired or a significant network topology change
+ occurs. One method of doing this is to limit the rate of updates.
+ This will eliminate the redundant scanning of the routing table to
+ provide flash updates for BGP peers and other routing protocols. A
+ disadvantage of this approach is that it increases the propagation
+ latency of routing information. By choosing a minimum flash update
+ interval that is not much greater than the time it takes to process
+ the multiple messages this latency should be minimized. A better
+ method would be to read all received messages before sending updates.
+
+6.2 Processing Messages on a Stream Protocol
+
+ BGP uses TCP as a transport mechanism. Due to the stream nature of
+ TCP, all the data for received messages does not necessarily arrive
+ at the same time. This can make it difficult to process the data as
+ messages, especially on systems such as BSD Unix where it is not
+ possible to determine how much data has been received but not yet
+ processed.
+
+ One method that can be used in this situation is to first try to read
+ just the message header. For the KEEPALIVE message type, this is a
+ complete message; for other message types, the header should first be
+ verified, in particular the total length. If all checks are
+ successful, the specified length, minus the size of the message
+ header is the amount of data left to read. An implementation that
+ would "hang" the routing information process while trying to read
+ from a peer could set up a message buffer (4096 bytes) per peer and
+ fill it with data as available until a complete message has been
+ received.
+
+6.3 Reducing route flapping
+
+ To avoid excessive route flapping a BGP speaker which needs to
+ withdraw a destination and send an update about a more specific or
+ less specific route shall combine them into the same UPDATE message.
+
+
+
+
+
+
+
+
+Rekhter & Li [Page 54]
+
+RFC 1771 BGP-4 March 1995
+
+
+6.4 BGP Timers
+
+ BGP employs five timers: ConnectRetry, Hold Time, KeepAlive,
+ MinASOriginationInterval, and MinRouteAdvertisementInterval The
+ suggested value for the ConnectRetry timer is 120 seconds. The
+ suggested value for the Hold Time is 90 seconds. The suggested value
+ for the KeepAlive timer is 30 seconds. The suggested value for the
+ MinASOriginationInterval is 15 seconds. The suggested value for the
+ MinRouteAdvertisementInterval is 30 seconds.
+
+ An implementation of BGP MUST allow these timers to be configurable.
+
+6.5 Path attribute ordering
+
+ Implementations which combine update messages as described above in
+ 6.1 may prefer to see all path attributes presented in a known order.
+ This permits them to quickly identify sets of attributes from
+ different update messages which are semantically identical. To
+ facilitate this, it is a useful optimization to order the path
+ attributes according to type code. This optimization is entirely
+ optional.
+
+6.6 AS_SET sorting
+
+ Another useful optimization that can be done to simplify this
+ situation is to sort the AS numbers found in an AS_SET. This
+ optimization is entirely optional.
+
+6.7 Control over version negotiation
+
+ Since BGP-4 is capable of carrying aggregated routes which cannot be
+ properly represented in BGP-3, an implementation which supports BGP-4
+ and another BGP version should provide the capability to only speak
+ BGP-4 on a per-peer basis.
+
+6.8 Complex AS_PATH aggregation
+
+ An implementation which chooses to provide a path aggregation
+ algorithm which retains significant amounts of path information may
+ wish to use the following procedure:
+
+ For the purpose of aggregating AS_PATH attributes of two routes,
+ we model each AS as a tuple <type, value>, where "type" identifies
+ a type of the path segment the AS belongs to (e.g. AS_SEQUENCE,
+ AS_SET), and "value" is the AS number. Two ASs are said to be the
+ same if their corresponding <type, value> tuples are the same.
+
+
+
+
+
+Rekhter & Li [Page 55]
+
+RFC 1771 BGP-4 March 1995
+
+
+ The algorithm to aggregate two AS_PATH attributes works as
+ follows:
+
+ a) Identify the same ASs (as defined above) within each AS_PATH
+ attribute that are in the same relative order within both
+ AS_PATH attributes. Two ASs, X and Y, are said to be in the
+ same order if either:
+
+ - X precedes Y in both AS_PATH attributes, or - Y precedes X
+ in both AS_PATH attributes.
+
+ b) The aggregated AS_PATH attribute consists of ASs identified
+ in (a) in exactly the same order as they appear in the AS_PATH
+ attributes to be aggregated. If two consecutive ASs identified
+ in (a) do not immediately follow each other in both of the
+ AS_PATH attributes to be aggregated, then the intervening ASs
+ (ASs that are between the two consecutive ASs that are the
+ same) in both attributes are combined into an AS_SET path
+ segment that consists of the intervening ASs from both AS_PATH
+ attributes; this segment is then placed in between the two
+ consecutive ASs identified in (a) of the aggregated attribute.
+ If two consecutive ASs identified in (a) immediately follow
+ each other in one attribute, but do not follow in another, then
+ the intervening ASs of the latter are combined into an AS_SET
+ path segment; this segment is then placed in between the two
+ consecutive ASs identified in (a) of the aggregated attribute.
+
+ If as a result of the above procedure a given AS number appears
+ more than once within the aggregated AS_PATH attribute, all, but
+ the last instance (rightmost occurrence) of that AS number should
+ be removed from the aggregated AS_PATH attribute.
+
+References
+
+ [1] Mills, D., "Exterior Gateway Protocol Formal Specification", RFC
+ 904, BBN, April 1984.
+
+ [2] Rekhter, Y., "EGP and Policy Based Routing in the New NSFNET
+ Backbone", RFC 1092, T.J. Watson Research Center, February 1989.
+
+ [3] Braun, H-W., "The NSFNET Routing Architecture", RFC 1093,
+ MERIT/NSFNET Project, February 1989.
+
+ [4] Postel, J., "Transmission Control Protocol - DARPA Internet
+ Program Protocol Specification", STD 7, RFC 793, DARPA, September
+ 1981.
+
+
+
+
+
+Rekhter & Li [Page 56]
+
+RFC 1771 BGP-4 March 1995
+
+
+ [5] Rekhter, Y., and P. Gross, "Application of the Border Gateway
+ Protocol in the Internet", RFC 1772, T.J. Watson Research Center,
+ IBM Corp., MCI, March 1995.
+
+ [6] Postel, J., "Internet Protocol - DARPA Internet Program Protocol
+ Specification", STD 5, RFC 791, DARPA, September 1981.
+
+ [7] "Information Processing Systems - Telecommunications and
+ Information Exchange between Systems - Protocol for Exchange of
+ Inter-domain Routeing Information among Intermediate Systems to
+ Support Forwarding of ISO 8473 PDUs", ISO/IEC IS10747, 1993
+
+ [8] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-
+ Domain Routing (CIDR): an Address Assignment and Aggregation
+ Strategy", RFC 1519, BARRNet, cisco, MERIT, OARnet, September
+ 1993
+
+ [9] Rekhter, Y., Li, T., "An Architecture for IP Address Allocation
+ with CIDR", RFC 1518, T.J. Watson Research Center, cisco,
+ September 1993
+
+Security Considerations
+
+ Security issues are not discussed in this document.
+
+Editors' Addresses
+
+ Yakov Rekhter
+ T.J. Watson Research Center IBM Corporation
+ P.O. Box 704, Office H3-D40
+ Yorktown Heights, NY 10598
+
+ Phone: +1 914 784 7361
+ EMail: yakov@watson.ibm.com
+
+
+ Tony Li
+ cisco Systems, Inc.
+ 170 W. Tasman Dr.
+ San Jose, CA 95134
+
+ EMail: tli@cisco.com
+
+
+
+
+
+
+
+
+
+Rekhter & Li [Page 57]
+
diff --git a/doc/rfc4360.txt b/doc/rfc4360.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group S. Sangli
+Request for Comments: 4360 D. Tappan
+Category: Standards Track Cisco Systems
+ Y. Rekhter
+ Juniper Networks
+ February 2006
+
+
+ BGP Extended Communities Attribute
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ This document describes the "extended community" BGP-4 attribute.
+ This attribute provides a mechanism for labeling information carried
+ in BGP-4. These labels can be used to control the distribution of
+ this information, or for other applications.
+
+1. Introduction
+
+ The Extended Community Attribute provides a mechanism for labeling
+ information carried in BGP-4 [BGP-4]. It provides two important
+ enhancements over the existing BGP Community Attribute [RFC1997]:
+
+ - An extended range, ensuring that communities can be assigned for
+ a plethora of uses, without fear of overlap.
+
+ - The addition of a Type field provides structure for the
+ community space.
+
+ The addition of structure allows the usage of policy based on the
+ application for which the community value will be used. For example,
+ one can filter out all communities of a particular type, or allow
+ only certain values for a particular type of community. It also
+ allows one to specify whether a particular community is transitive or
+ non-transitive across an Autonomous System (AS) boundary. Without
+ structure, this can only be accomplished by explicitly enumerating
+
+
+
+Sangli, et al. Standards Track [Page 1]
+
+RFC 4360 BGP Extended Communities Attribute February 2006
+
+
+ all community values that will be denied or allowed and passed to BGP
+ speakers in neighboring ASes based on the transitive property.
+
+1.1. Specification of Requirements
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [RFC2119].
+
+2. BGP Extended Communities Attribute
+
+ The Extended Communities Attribute is a transitive optional BGP
+ attribute, with the Type Code 16. The attribute consists of a set of
+ "extended communities". All routes with the Extended Communities
+ attribute belong to the communities listed in the attribute.
+
+ Each Extended Community is encoded as an 8-octet quantity, as
+ follows:
+
+ - Type Field : 1 or 2 octets
+ - Value Field : Remaining octets
+
+ 0 1 2 3
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type high | Type low(*) | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ (*) Present for Extended types only, used for the Value field
+ otherwise.
+
+ Type Field:
+
+ Two classes of Type Field are introduced: Regular type and
+ Extended type.
+
+ The size of Type Field for Regular types is 1 octet, and the
+ size of the Type Field for Extended types is 2 octets.
+
+ The value of the high-order octet of the Type Field determines
+ if an extended community is a Regular type or an Extended type.
+ The class of a type (Regular or Extended) is not encoded in the
+ structure of the type itself. The class of a type is specified
+ in the document that defines the type and the IANA registry.
+
+
+
+
+
+Sangli, et al. Standards Track [Page 2]
+
+RFC 4360 BGP Extended Communities Attribute February 2006
+
+
+ The high-order octet of the Type Field is as shown below:
+
+ 0 1 2 3 4 5 6 7
+ +-+-+-+-+-+-+-+-+
+ |I|T| |
+ +-+-+-+-+-+-+-+-+
+
+ I - IANA authority bit
+
+ Value 0: IANA-assignable type using the "First Come First
+ Serve" policy
+
+ Value 1: Part of this Type Field space is for IANA
+ assignable types using either the Standard Action or the
+ Early IANA Allocation policy. The rest of this Type
+ Field space is for Experimental use.
+
+ T - Transitive bit
+
+ Value 0: The community is transitive across ASes
+
+ Value 1: The community is non-transitive across ASes
+
+ Remaining 6 bits: Indicates the structure of the community
+
+ Value Field:
+
+ The encoding of the Value Field is dependent on the "type" of
+ the community as specified by the Type Field.
+
+ Two extended communities are declared equal only when all 8 octets of
+ the community are equal.
+
+ The two members in the tuple <Type, Value> should be enumerated to
+ specify any community value. The remaining octets of the community
+ interpreted based on the value of the Type field.
+
+3. Defined BGP Extended Community Types
+
+ This section introduces a few extended types and defines the format
+ of the Value Field for those types. The types introduced here
+ provide "templates", where each template is identified by the high-
+ order octet of the extended community Type field, and the lower-order
+ octet (sub-type) is used to indicate a particular type of extended
+ community.
+
+
+
+
+
+
+Sangli, et al. Standards Track [Page 3]
+
+RFC 4360 BGP Extended Communities Attribute February 2006
+
+
+3.1. Two-Octet AS Specific Extended Community
+
+ This is an extended type with Type Field composed of 2 octets and
+ Value Field composed of 6 octets.
+
+ 0 1 2 3
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 0x00 or 0x40 | Sub-Type | Global Administrator |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Local Administrator |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The value of the high-order octet of this extended type is either
+ 0x00 or 0x40. The low-order octet of this extended type is used to
+ indicate sub-types.
+
+ The Value Field consists of two sub-fields:
+
+ Global Administrator sub-field: 2 octets
+
+ This sub-field contains an Autonomous System number assigned by
+ IANA.
+
+ Local Administrator sub-field: 4 octets
+
+ The organization identified by Autonomous System number in the
+ Global Administrator sub-field can encode any information in
+ this sub-field. The format and meaning of the value encoded in
+ this sub-field should be defined by the sub-type of the
+ community.
+
+3.2. IPv4 Address Specific Extended Community
+
+ This is an extended type with Type Field composed of 2 octets and
+ Value Field composed of 6 octets.
+
+ 0 1 2 3
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 0x01 or 0x41 | Sub-Type | Global Administrator |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Global Administrator (cont.) | Local Administrator |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The value of the high-order octet of this extended type is either
+ 0x01 or 0x41. The low-order octet of this extended type is used to
+ indicate sub-types.
+
+
+
+Sangli, et al. Standards Track [Page 4]
+
+RFC 4360 BGP Extended Communities Attribute February 2006
+
+
+ The Value field consists of two sub-fields:
+
+ Global Administrator sub-field: 4 octets
+
+ This sub-field contains an IPv4 unicast address assigned by one
+ of the Internet registries.
+
+ Local Administrator sub-field: 2 octets
+
+ The organization that has been assigned the IPv4 address in the
+ Global Administrator sub-field can encode any information in
+ this sub-field. The format and meaning of this value encoded
+ in this sub-field should be defined by the sub-type of the
+ community.
+
+3.3. Opaque Extended Community
+
+ This is an extended type with Type Field composed of 2 octets and
+ Value Field composed of 6 octets.
+
+ 0 1 2 3
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 0x03 or 0x43 | Sub-Type | Value |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Value (cont.) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The value of the high-order octet of this extended type is either
+ 0x03 or 0x43. The low-order octet of this extended type is used to
+ indicate sub-types.
+
+ This is a generic community of extended type. The value of the sub-
+ type that should define the Value Field is to be assigned by IANA.
+
+4. Route Target Community
+
+ The Route Target Community identifies one or more routers that may
+ receive a set of routes (that carry this Community) carried by BGP.
+ This is transitive across the Autonomous System boundary.
+
+ The Route Target Community is of an extended type.
+
+ The value of the high-order octet of the Type field for the Route
+ Target Community can be 0x00, 0x01, or 0x02. The value of the low-
+ order octet of the Type field for this community is 0x02.
+
+
+
+
+
+Sangli, et al. Standards Track [Page 5]
+
+RFC 4360 BGP Extended Communities Attribute February 2006
+
+
+ When the value of the high-order octet of the Type field is 0x00 or
+ 0x02, the Local Administrator sub-field contains a number from a
+ numbering space that is administered by the organization to which the
+ Autonomous System number carried in the Global Administrator sub-
+ field has been assigned by an appropriate authority.
+
+ When the value of the high-order octet of the Type field is 0x01, the
+ Local Administrator sub-field contains a number from a numbering
+ space that is administered by the organization to which the IP
+ address carried in the Global Administrator sub-field has been
+ assigned by an appropriate authority.
+
+ One possible use of the Route Target Community is specified in
+ [RFC4364].
+
+5. Route Origin Community
+
+ The Route Origin Community identifies one or more routers that inject
+ a set of routes (that carry this Community) into BGP. This is
+ transitive across the Autonomous System boundary.
+
+ The Route Origin Community is of an extended type.
+
+ The value of the high-order octet of the Type field for the Route
+ Origin Community can be 0x00, 0x01, or 0x02. The value of the low-
+ order octet of the Type field for this community is 0x03.
+
+ When the value of the high-order octet of the Type field is 0x00 or
+ 0x02, the Local Administrator sub-field contains a number from a
+ numbering space that is administered by the organization to which the
+ Autonomous System number carried in the Global Administrator sub-
+ field has been assigned by an appropriate authority.
+
+ When the value of the high-order octet of the Type field is 0x01, the
+ Local Administrator sub-field contains a number from a numbering
+ space that is administered by the organization to which the IP
+ address carried in the Global Administrator sub-field has been
+ assigned by an appropriate authority.
+
+ One possible use of the Route Origin Community is specified in
+ [RFC4364].
+
+
+
+
+
+
+
+
+
+
+Sangli, et al. Standards Track [Page 6]
+
+RFC 4360 BGP Extended Communities Attribute February 2006
+
+
+6. Operations
+
+ A BGP speaker may use the Extended Communities attribute to control
+ which routing information it accepts or distributes to its peers.
+
+ The Extended Community attribute MUST NOT be used to modify the BGP
+ best path selection algorithm in a way that leads to forwarding
+ loops.
+
+ A BGP speaker receiving a route that doesn't have the Extended
+ Communities attribute MAY append this attribute to the route when
+ propagating it to its peers.
+
+ A BGP speaker receiving a route with the Extended Communities
+ attribute MAY modify this attribute according to the local policy.
+
+ By default if a range of routes is to be aggregated and the resultant
+ aggregates path attributes do not carry the ATOMIC_AGGREGATE
+ attribute, then the resulting aggregate should have an Extended
+ Communities path attribute that contains the set union of all the
+ Extended Communities from all of the aggregated routes. The default
+ behavior could be overridden via local configuration, in which case
+ handling the Extended Communities attribute in the presence of route
+ aggregation becomes a matter of the local policy of the BGP speaker
+ that performs the aggregation.
+
+ If a route has a non-transitivity extended community, then before
+ advertising the route across the Autonomous System boundary the
+ community SHOULD be removed from the route. However, the community
+ SHOULD NOT be removed when advertising the route across the BGP
+ Confederation boundary.
+
+ A route may carry both the BGP Communities attribute, as defined in
+ [RFC1997]), and the Extended BGP Communities attribute. In this
+ case, the BGP Communities attribute is handled as specified in
+ [RFC1997], and the Extended BGP Communities attribute is handled as
+ specified in this document.
+
+7. IANA Considerations
+
+ All the BGP Extended Communities contain a Type field. The IANA has
+ created a registry entitled, "BGP Extended Communities Type". The
+ IANA will maintain this registry.
+
+ The Type could be either regular or extended. For a regular Type the
+ IANA allocates an 8-bit value; for an extended Type the IANA
+ allocates a 16-bit value.
+
+
+
+
+Sangli, et al. Standards Track [Page 7]
+
+RFC 4360 BGP Extended Communities Attribute February 2006
+
+
+ The value allocated for a regular Type MUST NOT be reused as the
+ value of the high-order octet when allocating an extended Type. The
+ value of the high-order octet allocated for an extended Type MUST NOT
+ be reused when allocating a regular Type.
+
+ The Type field indicates where the Extended Community is transitive
+ or not. Future requests for assignment of a Type value must specify
+ whether the Type value is intended for a transitive or a non-
+ transitive Extended Community.
+
+ Future assignment are to be made using either the Standards Action
+ process defined in [RFC2434], the Early IANA Allocation process
+ defined in [RFC4020], or the "First Come First Served" policy defined
+ in [RFC2434].
+
+ The following table summarizes the ranges for the assignment of
+ Types:
+
+ Type Standard Action First Come
+ Early IANA Allocation First Served
+ ------------------ --------------------- ------------
+
+ regular, transitive 0x90-0xbf 0x00-x3f
+
+ regular, non-transitive 0xd0-0xff 0x40-0x7f
+
+ extended, transitive 0x9000-0xbfff 0x0000-0x3fff
+
+ extended, non-transitive 0xd000-0xffff 0x4000-0x7fff
+
+ Assignments consist of a name and the value.
+
+ The Type values 0x80-0x8f and 0xc0-0xcf for regular Types, and
+ 0x8000-0x8fff and 0xc000-0xcfff for extended Types are for
+ Experimental use as defined in RFC 3692.
+
+ This document defines a class of extended communities called two-
+ octet AS specific extended community for which the IANA is to create
+ and maintain a registry entitled "Two-octet AS Specific Extended
+ Community". All the communities in this class are of extended Types.
+ Future assignment are to be made using the "First Come First Served"
+ policy defined in [RFC2434]. The Type values for the transitive
+ communities of the two-octet AS specific extended community class are
+ 0x0000-0x00ff, and for the non-transitive communities of that class
+ are 0x4000-0x40ff. Assignments consist of a name and the value.
+
+ This document makes the following assignments for the two-octet AS
+ specific extended community:
+
+
+
+Sangli, et al. Standards Track [Page 8]
+
+RFC 4360 BGP Extended Communities Attribute February 2006
+
+
+ Name Type Value
+ ---- ----------
+ two-octet AS specific Route Target 0x0002
+ two-octet AS specific Route Origin 0x0003
+
+ This document defines a class of extended communities called IPv4
+ address specific extended community for which the IANA is to create
+ and maintain a registry entitled "IPv4 Address Specific Extended
+ Community". All the communities in this class are of extended Types.
+ Future assignment are to be made using the "First Come First Served"
+ policy defined in [RFC2434]. The Type values for the transitive
+ communities of the two-octet AS specific extended community class
+ are 0x0100-0x01ff, and for the non-transitive communities of that
+ class are 0x4100-0x41ff. Assignments consist of a name and the
+ value.
+
+ This document makes the following assignments for the IPv4 address
+ specific extended community:
+
+ Name Type Value
+ ---- ----------
+ IPv4 address specific Route Target 0x0102
+ IPv4 address specific Route Origin 0x0103
+
+ This document defines a class of extended communities called opaque
+ extended community for which the IANA is to create and maintain a
+ registry entitled "Opaque Extended Community". All the communities
+ in this class are of extended Types. Future assignment are to be
+ made using the "First Come First Served" policy defined in [RFC2434].
+ The Type values for the transitive communities of the opaque extended
+ community class are 0x0300-0x03ff, and for the non-transitive
+ communities of that class are 0x4300-0x43ff. Assignments consist of
+ a name and the value.
+
+ When requesting an allocation from more than one registry defined
+ above, one may ask for allocating the same Type value from these
+ registries. If possible, the IANA should accommodate such requests.
+
+8. Security Considerations
+
+ This extension to BGP has similar security implications as BGP
+ Communities [RFC1997].
+
+ This extension to BGP does not change the underlying security issues.
+ Specifically, an operator who is relying on the information carried
+ in BGP must have a transitive trust relationship back to the source
+ of the information. Specifying the mechanism(s) to provide such a
+ relationship is beyond the scope of this document.
+
+
+
+Sangli, et al. Standards Track [Page 9]
+
+RFC 4360 BGP Extended Communities Attribute February 2006
+
+
+9. Acknowledgements
+
+ The authors would like to thank John Hawkinson, Jeffrey Haas, Bruno
+ Rijsman, Bill Fenner, and Alex Zinin for their suggestions and
+ feedback.
+
+10. Normative References
+
+ [BGP-4] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
+ (BGP-4)", RFC 4271, January 2006.
+
+ [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities
+ Attribute", RFC 1997, August 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
+ an IANA Considerations Section in RFCs", BCP 26, RFC
+ 2434, October 1998.
+
+ [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of
+ Standards Track Code Points", BCP 100, RFC 4020,
+ February 2005.
+
+11. Informative References
+
+ [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
+ Networks (VPNs)", RFC 4364, February 2006.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sangli, et al. Standards Track [Page 10]
+
+RFC 4360 BGP Extended Communities Attribute February 2006
+
+
+Authors' Addresses
+
+ Srihari R. Sangli
+ Cisco Systems, Inc.
+
+ EMail: rsrihari@cisco.com
+
+
+ Dan Tappan
+ Cisco Systems, Inc.
+ 250 Apollo Drive
+ Chelmsford, MA 01824
+
+ EMail: tappan@cisco.com
+
+
+ Yakov Rekhter
+ Juniper Networks, Inc.
+ 1194 N. Mathilda Ave
+ Sunnyvale, CA 94089
+
+ EMail: yakov@juniper.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sangli, et al. Standards Track [Page 11]
+
+RFC 4360 BGP Extended Communities Attribute February 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Sangli, et al. Standards Track [Page 12]
+
diff --git a/doc/rfc4364.txt b/doc/rfc4364.txt
@@ -0,0 +1,2635 @@
+
+
+
+
+
+
+Network Working Group E. Rosen
+Request for Comments: 4364 Cisco Systems, Inc.
+Obsoletes: 2547 Y. Rekhter
+Category: Standards Track Juniper Networks, Inc.
+ February 2006
+
+
+ BGP/MPLS IP Virtual Private Networks (VPNs)
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ This document describes a method by which a Service Provider may use
+ an IP backbone to provide IP Virtual Private Networks (VPNs) for its
+ customers. This method uses a "peer model", in which the customers'
+ edge routers (CE routers) send their routes to the Service Provider's
+ edge routers (PE routers); there is no "overlay" visible to the
+ customer's routing algorithm, and CE routers at different sites do
+ not peer with each other. Data packets are tunneled through the
+ backbone, so that the core routers do not need to know the VPN
+ routes.
+
+ This document obsoletes RFC 2547.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosen & Rekhter Standards Track [Page 1]
+
+RFC 4364 BGP/MPLS IP VPNs February 2006
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Virtual Private Networks ...................................4
+ 1.2. Customer Edge and Provider Edge ............................5
+ 1.3. VPNs with Overlapping Address Spaces .......................6
+ 1.4. VPNs with Different Routes to the Same System ..............7
+ 1.5. SP Backbone Routers ........................................7
+ 1.6. Security ...................................................8
+ 2. Sites and CEs ...................................................8
+ 3. VRFs: Multiple Forwarding Tables in PEs .........................9
+ 3.1. VRFs and Attachment Circuits ...............................9
+ 3.2. Associating IP Packets with VRFs ..........................10
+ 3.3. Populating the VRFs .......................................11
+ 4. VPN Route Distribution via BGP .................................12
+ 4.1. The VPN-IPv4 Address Family ...............................13
+ 4.2. Encoding of Route Distinguishers ..........................14
+ 4.3. Controlling Route Distribution ............................15
+ 4.3.1. The Route Target Attribute .........................15
+ 4.3.2. Route Distribution Among PEs by BGP ................17
+ 4.3.3. Use of Route Reflectors ............................20
+ 4.3.4. How VPN-IPv4 NLRI Is Carried in BGP ................22
+ 4.3.5. Building VPNs Using Route Targets ..................23
+ 4.3.6. Route Distribution Among VRFs in a Single PE .......23
+ 5. Forwarding .....................................................23
+ 6. Maintaining Proper Isolation of VPNs ...........................26
+ 7. How PEs Learn Routes from CEs ..................................27
+ 8. How CEs Learn Routes from PEs ..................................30
+ 9. Carriers' Carriers .............................................30
+ 10. Multi-AS Backbones ............................................32
+ 11. Accessing the Internet from a VPN .............................34
+ 12. Management VPNs ...............................................36
+ 13. Security Considerations .......................................37
+ 13.1. Data Plane ...............................................37
+ 13.2. Control Plane ............................................39
+ 13.3. Security of P and PE Devices .............................39
+ 14. Quality of Service ............................................39
+ 15. Scalability ...................................................40
+ 16. IANA Considerations ...........................................40
+ 17. Acknowledgements ..............................................41
+ 18. Contributors ..................................................41
+ 19. Normative References ..........................................44
+ 20. Informative References ........................................45
+
+
+
+
+
+
+
+
+Rosen & Rekhter Standards Track [Page 2]
+
+RFC 4364 BGP/MPLS IP VPNs February 2006
+
+
+1. Introduction
+
+ This document describes a method by which a Service Provider may use
+ an IP backbone to provide IP Virtual Private Networks (VPNs) for its
+ customers. This method uses a "peer model", in which the customers'
+ edge routers (CE routers) send their routes to the Service Provider's
+ edge routers (PE routers). Border Gateway Protocol (BGP)
+ [BGP, BGP-MP] is then used by the Service Provider to exchange the
+ routes of a particular VPN among the PE routers that are attached to
+ that VPN. This is done in a way that ensures that routes from
+ different VPNs remain distinct and separate, even if two VPNs have an
+ overlapping address space. The PE routers distribute, to the CE
+ routers in a particular VPN, the routes from other the CE routers in
+ that VPN. The CE routers do not peer with each other, hence there is
+ no "overlay" visible to the VPN's routing algorithm. The term "IP"
+ in "IP VPN" is used to indicate that the PE receives IP datagrams
+ from the CE, examines their IP headers, and routes them accordingly.
+
+ Each route within a VPN is assigned a Multiprotocol Label Switching
+ (MPLS) [MPLS-ARCH, MPLS-BGP, MPLS-ENCAPS] label; when BGP distributes
+ a VPN route, it also distributes an MPLS label for that route.
+ Before a customer data packet travels across the Service Provider's
+ backbone, it is encapsulated with the MPLS label that corresponds, in
+ the customer's VPN, to the route that is the best match to the
+ packet's destination address. This MPLS packet is further
+ encapsulated (e.g., with another MPLS label or with an IP or Generic
+ Routing Encapsulation (GRE) tunnel header [MPLS-in-IP-GRE]) so that
+ it gets tunneled across the backbone to the proper PE router. Thus,
+ the backbone core routers do not need to know the VPN routes.
+
+ The primary goal of this method is to support the case in which a
+ client obtains IP backbone services from a Service Provider or
+ Service Providers with which it maintains contractual relationships.
+ The client may be an enterprise, a group of enterprises that need an
+ extranet, an Internet Service Provider, an application service
+ provider, another VPN Service Provider that uses this same method to
+ offer VPNs to clients of its own, etc. The method makes it very
+ simple for the client to use the backbone services. It is also very
+ scalable and flexible for the Service Provider, and allows the
+ Service Provider to add value.
+
+
+
+
+
+
+
+
+
+
+
+Rosen & Rekhter Standards Track [Page 3]
+
+RFC 4364 BGP/MPLS IP VPNs February 2006
+
+
+1.1. Virtual Private Networks
+
+ Consider a set of "sites" that are attached to a common network that
+ we call "the backbone". Now apply some policy to create a number of
+ subsets of that set, and impose the following rule: two sites may
+ have IP interconnectivity over that backbone only if at least one of
+ these subsets contains them both.
+
+ These subsets are Virtual Private Networks (VPNs). Two sites have IP
+ connectivity over the common backbone only if there is some VPN that
+ contains them both. Two sites that have no VPN in common have no
+ connectivity over that backbone.
+
+ If all the sites in a VPN are owned by the same enterprise, the VPN
+ may be thought of as a corporate "intranet". If the various sites in
+ a VPN are owned by different enterprises, the VPN may be thought of
+ as an "extranet". A site can be in more than one VPN; e.g., in an
+ intranet and in several extranets. In general, when we use the term
+ "VPN" we will not be distinguishing between intranets and extranets.
+
+ We refer to the owners of the sites as the "customers". We refer to
+ the owners/operators of the backbone as the "Service Providers"
+ (SPs). The customers obtain "VPN service" from the SPs.
+
+ A customer may be a single enterprise, a set of enterprises, an
+ Internet Service Provider, an Application Service Provider, another
+ SP that offers the same kind of VPN service to its own customers,
+ etc.
+
+ The policies that determine whether a particular collection of sites
+ is a VPN are the policies of the customers. Some customers will want
+ the implementation of these policies to be entirely the
+ responsibility of the SP. Other customers may want to share with the
+ SP the responsibility for implementing these policies. This document
+ specifies mechanisms that can be used to implement these policies.
+ The mechanisms we describe are general enough to allow these policies
+ to be implemented either by the SP alone or by a VPN customer
+ together with the SP. Most of the discussion is focused on the
+ former case, however.
+
+ The mechanisms discussed in this document allow the implementation of
+ a wide range of policies. For example, within a given VPN, one can
+ allow every site to have a direct route to every other site ("full
+ mesh"). Alternatively, one can force traffic between certain pairs
+ of sites to be routed via a third site. This can be useful, e.g., if
+ it is desired that traffic between a pair of sites be passed through
+ a firewall, and the firewall is located at the third site.
+
+
+
+
+Rosen & Rekhter Standards Track [Page 4]
+
+RFC 4364 BGP/MPLS IP VPNs February 2006
+
+
+ In this document, we restrict our discussion to the case in which the
+ customer is explicitly purchasing VPN service from an SP, or from a
+ set of SPs that have agreed to cooperate to provide the VPN service.
+ That is, the customer is not merely purchasing internet access from
+ an SP, and the VPN traffic does not pass through a random collection
+ of interconnected SP networks.
+
+ We also restrict our discussion to the case in which the backbone
+ provides an IP service to the customer, rather than, e.g., a layer 2
+ service such as Frame Relay, Asynchronous Transfer Mode (ATM),
+ ethernet, High Level Data Link Control (HDLC), or Point-to-Point
+ Protocol (PPP). The customer may attach to the backbone via one of
+ these (or other) layer 2 services, but the layer 2 service is
+ terminated at the "edge" of the backbone, where the customer's IP
+ datagrams are removed from any layer 2 encapsulation.
+
+ In the rest of this introduction, we specify some properties that
+ VPNs should have. The remainder of this document specifies a set of
+ mechanisms that can be deployed to provide a VPN model that has all
+ these properties. This section also introduces some of the technical
+ terminology used in the remainder of the document.
+
+1.2. Customer Edge and Provider Edge
+
+ Routers can be attached to each other, or to end systems, in a
+ variety of different ways: PPP connections, ATM Virtual Circuits
+ (VCs), Frame Relay VCs, ethernet interfaces, Virtual Local Area
+ Networks (VLANs) on ethernet interfaces, GRE tunnels, Layer 2
+ Tunneling Protocol (L2TP) tunnels, IPsec tunnels, etc. We will use
+ the term "attachment circuit" to refer generally to some such means
+ of attaching to a router. An attachment circuit may be the sort of
+ connection that is usually thought of as a "data link", or it may be
+ a tunnel of some sort; what matters is that it be possible for two
+ devices to be network layer peers over the attachment circuit.
+
+ Each VPN site must contain one or more Customer Edge (CE) devices.
+ Each CE device is attached, via some sort of attachment circuit, to
+ one or more Provider Edge (PE) routers.
+
+ Routers in the SP's network that do not attach to CE devices are
+ known as "P routers".
+
+ CE devices can be hosts or routers. In a typical case, a site
+ contains one or more routers, some of which are attached to PE
+ routers. The site routers that attach to the PE routers would then
+ be the CE devices, or "CE routers". However, there is nothing to
+ prevent a non-routing host from attaching directly to a PE router, in
+ which case the host would be a CE device.
+
+
+
+Rosen & Rekhter Standards Track [Page 5]
+
+RFC 4364 BGP/MPLS IP VPNs February 2006
+
+
+ Sometimes, what is physically attached to a PE router is a layer 2
+ switch. In this case, we do NOT say that the layer 2 switch is a CE
+ device. Rather, the CE devices are the hosts and routers that
+ communicate with the PE router through the layer 2 switch; the layer
+ 2 infrastructure is transparent. If the layer 2 infrastructure
+ provides a multipoint service, then multiple CE devices can be
+ attached to the PE router over the same attachment circuit.
+
+ CE devices are logically part of a customer's VPN. PE and P routers
+ are logically part of the SP's network.
+
+ The attachment circuit over which a packet travels when going from CE
+ to PE is known as that packet's "ingress attachment circuit", and the
+ PE as the packet's "ingress PE". The attachment circuit over which a
+ packet travels when going from PE to CE is known as that packet's
+ "egress attachment circuit", and the PE as the packet's "egress PE".
+
+ We will say that a PE router is attached to a particular VPN if it is
+ attached to a CE device that is in a site of that VPN. Similarly, we
+ will say that a PE router is attached to a particular site if it is
+ attached to a CE device that is in that site.
+
+ When the CE device is a router, it is a routing peer of the PE(s) to
+ which it is attached, but it is NOT a routing peer of CE routers at
+ other sites. Routers at different sites do not directly exchange
+ routing information with each other; in fact, they do not even need
+ to know of each other at all. As a consequence, the customer has no
+ backbone or "virtual backbone" to manage, and does not have to deal
+ with any inter-site routing issues. In other words, in the scheme
+ described in this document, a VPN is NOT an "overlay" on top of the
+ SP's network.
+
+ With respect to the management of the edge devices, clear
+ administrative boundaries are maintained between the SP and its
+ customers. Customers are not required to access the PE or P routers
+ for management purposes, nor is the SP required to access the CE
+ devices for management purposes.
+
+1.3. VPNs with Overlapping Address Spaces
+
+ If two VPNs have no sites in common, then they may have overlapping
+ address spaces. That is, a given address might be used in VPN V1 as
+ the address of system S1, but in VPN V2 as the address of a
+ completely different system S2. This is a common situation when the
+ VPNs each use an RFC 1918 private address space. Of course, within
+ each VPN, each address must be unambiguous.
+
+
+
+
+
+Rosen & Rekhter Standards Track [Page 6]
+
+RFC 4364 BGP/MPLS IP VPNs February 2006
+
+
+ Even two VPNs that do have sites in common may have overlapping
+ address spaces, as long as there is no need for any communication
+ between systems with such addresses and systems in the common sites.
+
+1.4. VPNs with Different Routes to the Same System
+
+ Although a site may be in multiple VPNs, it is not necessarily the
+ case that the route to a given system at that site should be the same
+ in all the VPNs. Suppose, for example, we have an intranet
+ consisting of sites A, B, and C, and an extranet consisting of A, B,
+ C, and the "foreign" site D. Suppose that at site A there is a
+ server, and we want clients from B, C, or D to be able to use that
+ server. Suppose also that at site B there is a firewall. We want
+ all the traffic from site D to the server to pass through the
+ firewall, so that traffic from the extranet can be access controlled.
+ However, we don't want traffic from C to pass through the firewall on
+ the way to the server, since this is intranet traffic.
+
+ It is possible to set up two routes to the server. One route, used
+ by sites B and C, takes the traffic directly to site A. The second
+ route, used by site D, takes the traffic instead to the firewall at
+ site B. If the firewall allows the traffic to pass, it then appears
+ to be traffic coming from site B, and follows the route to site A.
+
+1.5. SP Backbone Routers
+
+ The SP's backbone consists of the PE routers, as well as other
+ routers ("P routers") that do not attach to CE devices.
+
+ If every router in an SP's backbone had to maintain routing
+ information for all the VPNs supported by the SP, there would be
+ severe scalability problems; the number of sites that could be
+ supported would be limited by the amount of routing information that
+ could be held in a single router. It is important therefore that the
+ routing information about a particular VPN only needs to be present
+ in the PE routers that attach to that VPN. In particular, the P
+ routers do not need to have ANY per-VPN routing information
+ whatsoever. (This condition may need to be relaxed somewhat when
+ multicast routing is considered. This is not considered further in
+ this paper, but is examined in [VPN-MCAST].)
+
+ So just as the VPN owners do not have a backbone or "virtual
+ backbone" to administer, the SPs themselves do not have a separate
+ backbone or "virtual backbone" to administer for each VPN. Site-to-
+ site routing in the backbone is optimal (within the constraints of
+ the policies used to form the VPNs) and is not constrained in any way
+ by an artificial "virtual topology" of tunnels.
+
+
+
+
+Rosen & Rekhter Standards Track [Page 7]
+
+RFC 4364 BGP/MPLS IP VPNs February 2006
+
+
+ Section 10 discusses some of the special issues that arise when the
+ backbone spans several Service Providers.
+
+1.6. Security
+
+ VPNs of the sort being discussed here, even without making use of
+ cryptographic security measures, are intended to provide a level of
+ security equivalent to that obtainable when a layer 2 backbone (e.g.,
+ Frame Relay) is used. That is, in the absence of misconfiguration or
+ deliberate interconnection of different VPNs, it is not possible for
+ systems in one VPN to gain access to systems in another VPN. Of
+ course, the methods described herein do not by themselves encrypt the
+ data for privacy, nor do they provide a way to determine whether data
+ has been tampered with en route. If this is desired, cryptographic
+ measures must be applied in addition. (See, e.g., [MPLS/BGP-IPsec].)
+ Security is discussed in more detail in Section 13.
+
+2. Sites and CEs
+
+ From the perspective of a particular backbone network, a set of IP
+ systems may be regarded as a "site" if those systems have mutual IP
+ interconnectivity that doesn't require use of the backbone. In
+ general, a site will consist of a set of systems that are in
+ geographic proximity. However, this is not universally true. If two
+ geographic locations are connected via a leased line, over which Open
+ Shortest Path First (OSPF) protocol [OSPFv2] is running, and if that
+ line is the preferred way of communicating between the two locations,
+ then the two locations can be regarded as a single site, even if each
+ location has its own CE router. (This notion of "site" is
+ topological, rather than geographical. If the leased line goes down,
+ or otherwise ceases to be the preferred route, but the two geographic
+ locations can continue to communicate by using the VPN backbone, then
+ one site has become two.)
+
+ A CE device is always regarded as being in a single site (though as
+ we shall see in Section 3.2, a site may consist of multiple "virtual
+ sites"). A site, however, may belong to multiple VPNs.
+
+ A PE router may attach to CE devices from any number of different
+ sites, whether those CE devices are in the same or in different VPNs.
+ A CE device may, for robustness, attach to multiple PE routers, of
+ the same or of different service providers. If the CE device is a
+ router, the PE router and the CE router will appear as router
+ adjacencies to each other.
+
+ While we speak mostly of "sites" as being the basic unit of
+ interconnection, nothing here prevents a finer degree of granularity
+ in the control of interconnectivity. For example, certain systems at
+
+
+
+Rosen & Rekhter Standards Track [Page 8]
+
+RFC 4364 BGP/MPLS IP VPNs February 2006
+
+
+ a site may be members of an intranet as well as members of one or
+ more extranets, while other systems at the same site may be
+ restricted to being members of the intranet only. However, this
+ might require that the site have two attachment circuits to the
+ backbone, one for the intranet and one for the extranet; it might
+ further require that firewall functionality be applied on the
+ extranet attachment circuit.
+
+3. VRFs: Multiple Forwarding Tables in PEs
+
+ Each PE router maintains a number of separate forwarding tables. One
+ of the forwarding tables is the "default forwarding table". The
+ others are "VPN Routing and Forwarding tables", or "VRFs".
+
+3.1. VRFs and Attachment Circuits
+
+ Every PE/CE attachment circuit is associated, by configuration, with
+ one or more VRFs. An attachment circuit that is associated with a
+ VRF is known as a "VRF attachment circuit".
+
+ In the simplest case and most typical case, a PE/CE attachment
+ circuit is associated with exactly one VRF. When an IP packet is
+ received over a particular attachment circuit, its destination IP
+ address is looked up in the associated VRF. The result of that
+ lookup determines how to route the packet. The VRF used by a
+ packet's ingress PE for routing a particular packet is known as the
+ packet's "ingress VRF". (There is also the notion of a packet's
+ "egress VRF", located at the packet's egress PE; this is discussed in
+ Section 5.)
+
+ If an IP packet arrives over an attachment circuit that is not
+ associated with any VRF, the packet's destination address is looked
+ up in the default forwarding table, and the packet is routed
+ accordingly. Packets forwarded according to the default forwarding
+ table include packets from neighboring P or PE routers, as well as
+ packets from customer-facing attachment circuits that have not been
+ associated with VRFs.
+
+ Intuitively, one can think of the default forwarding table as
+ containing "public routes", and of the VRFs as containing "private
+ routes". One can similarly think of VRF attachment circuits as being
+ "private", and of non-VRF attachment circuits as being "public".
+
+ If a particular VRF attachment circuit connects site S to a PE
+ router, then connectivity from S (via that attachment circuit) can be
+ restricted by controlling the set of routes that gets entered in the
+ corresponding VRF. The set of routes in that VRF should be limited
+ to the set of routes leading to sites that have at least one VPN in
+
+
+
+Rosen & Rekhter Standards Track [Page 9]
+
+RFC 4364 BGP/MPLS IP VPNs February 2006
+
+
+ common with S. Then a packet sent from S over a VRF attachment
+ circuit can only be routed by the PE to another site S' if S' is in
+ one of the same VPNs as S. That is, communication (via PE routers)
+ is prevented between any pair of VPN sites that have no VPN in
+ common. Communication between VPN sites and non-VPN sites is
+ prevented by keeping the routes to the VPN sites out of the default
+ forwarding table.
+
+ If there are multiple attachment circuits leading from S to one or
+ more PE routers, then there might be multiple VRFs that could be used
+ to route traffic from S. To properly restrict S's connectivity, the
+ same set of routes would have to exist in all the VRFs.
+ Alternatively, one could impose different connectivity restrictions
+ over different attachment circuit from S. In that case, some of the
+ VRFs associated with attachment circuits from S would contain
+ different sets of routes than some of the others.
+
+ We allow the case in which a single attachment circuit is associated
+ with a set of VRFs, rather than with a single VRF. This can be
+ useful if it is desired to divide a single VPN into several
+ "sub-VPNs", each with different connectivity restrictions, where some
+ characteristic of the customer packets is used to select from among
+ the sub-VPNs. For simplicity though, we will usually speak of an
+ attachment circuit as being associated with a single VRF.
+
+3.2. Associating IP Packets with VRFs
+
+ When a PE router receives a packet from a CE device, it must
+ determine the attachment circuit over which the packet arrived, as
+ this determines in turn the VRF (or set of VRFs) that can be used for
+ forwarding that packet. In general, to determine the attachment
+ circuit over which a packet arrived, a PE router takes note of the
+ physical interface over which the packet arrived, and possibly also
+ takes note of some aspect of the packet's layer 2 header. For
+ example, if a packet's ingress attachment circuit is a Frame Relay
+ VC, the identity of the attachment circuit can be determined from the
+ physical Frame Relay interface over which the packet arrived,
+ together with the Data Link Connection Identifier (DLCI) field in the
+ packet's Frame Relay header.
+
+ Although the PE's conclusion that a particular packet arrived on a
+ particular attachment circuit may be partially determined by the
+ packet's layer 2 header, it must be impossible for a customer, by
+ writing the header fields, to fool the SP into thinking that a packet
+ that was received over one attachment circuit really arrived over a
+ different one. In the example above, although the attachment circuit
+ is determined partially by inspection of the DLCI field in the Frame
+ Relay header, this field cannot be set freely by the customer.
+
+
+
+Rosen & Rekhter Standards Track [Page 10]
+
+RFC 4364 BGP/MPLS IP VPNs February 2006
+
+
+ Rather, it must be set to a value specified by the SP, or else the
+ packet cannot arrive at the PE router.
+
+ In some cases, a particular site may be divided by the customer into
+ several "virtual sites". The SP may designate a particular set of
+ VRFs to be used for routing packets from that site and may allow the
+ customer to set some characteristic of the packet, which is then used
+ for choosing a particular VRF from the set.
+
+ For example, each virtual site might be realized as a VLAN. The SP
+ and the customer could agree that on packets arriving from a
+ particular CE, certain VLAN values would be used to identify certain
+ VRFs. Of course, packets from that CE would be discarded by the PE
+ if they carry VLAN tag values that are not in the agreed-upon set.
+ Another way to accomplish this is to use IP source addresses. In
+ this case, the PE uses the IP source address in a packet received
+ from the CE, along with the interface over which the packet is
+ received, to assign the packet to a particular VRF. Again, the
+ customer would only be able to select from among the particular set
+ of VRFs that that customer is allowed to use.
+
+ If it is desired to have a particular host be in multiple virtual
+ sites, then that host must determine, for each packet, which virtual
+ site the packet is associated with. It can do this, e.g., by sending
+ packets from different virtual sites on different VLANs, or out
+ different network interfaces.
+
+3.3. Populating the VRFs
+
+ With what set of routes are the VRFs populated?
+
+ As an example, let PE1, PE2, and PE3 be three PE routers, and let
+ CE1, CE2, and CE3 be three CE routers. Suppose that PE1 learns, from
+ CE1, the routes that are reachable at CE1's site. If PE2 and PE3 are
+ attached, respectively, to CE2 and CE3, and there is some VPN V
+ containing CE1, CE2, and CE3, then PE1 uses BGP to distribute to PE2
+ and PE3 the routes that it has learned from CE1. PE2 and PE3 use
+ these routes to populate the VRFs that they associate, respectively,
+ with the sites of CE2 and CE3. Routes from sites that are not in VPN
+ V do not appear in these VRFs, which means that packets from CE2 or
+ CE3 cannot be sent to sites that are not in VPN V.
+
+ When we speak of a PE "learning" routes from a CE, we are not
+ presupposing any particular learning technique. The PE may learn
+ routes by means of a dynamic routing algorithm, but it may also
+ "learn" routes by having those routes configured (i.e., static
+ routing). (In this case, to say that the PE "learned" the routes
+ from the CE is perhaps to exercise a bit of poetic license.)
+
+
+
+Rosen & Rekhter Standards Track [Page 11]
+
+RFC 4364 BGP/MPLS IP VPNs February 2006
+
+
+ PEs also need to learn, from other PEs, the routes that belong to a
+ given VPN. The procedures to be used for populating the VRFs with
+ the proper sets of routes are specified in Section 4.
+
+ If there are multiple attachment circuits leading from a particular
+ PE router to a particular site, they might all be mapped to the same
+ forwarding table. But if policy dictates, they could be mapped to
+ different forwarding tables. For instance, the policy might be that
+ a particular attachment circuit from a site is used only for intranet
+ traffic, while another attachment circuit from that site is used only
+ for extranet traffic. (Perhaps, e.g., the CE attached to the
+ extranet attachment circuit is a firewall, while the CE attached to
+ the intranet attachment circuit is not.) In this case, the two
+ attachment circuits would be associated with different VRFs.
+
+ Note that if two attachment circuits are associated with the same
+ VRF, then packets that the PE receives over one of them will be able
+ to reach exactly the same set of destinations as packets that the PE
+ receives over the other. So two attachment circuits cannot be
+ associated with the same VRF unless each CE is in the exact same set
+ of VPNs as is the other.
+
+ If an attachment circuit leads to a site which is in multiple VPNs,
+ the attachment circuit may still associated with a single VRF, in
+ which case the VRF will contain routes from the full set of VPNs of
+ which the site is a member.
+
+4. VPN Route Distribution via BGP
+
+ PE routers use BGP to distribute VPN routes to each other (more
+ accurately, to cause VPN routes to be distributed to each other).
+
+ We allow each VPN to have its own address space, which means that a
+ given address may denote different systems in different VPNs. If two
+ routes to the same IP address prefix are actually routes to different
+ systems, it is important to ensure that BGP not treat them as
+ comparable. Otherwise, BGP might choose to install only one of them,
+ making the other system unreachable. Further, we must ensure that
+ POLICY is used to determine which packets get sent on which routes;
+ given that several such routes are installed by BGP, only one such
+ must appear in any particular VRF.
+
+ We meet these goals by the use of a new address family, as specified
+ below.
+
+
+
+
+
+
+
+Rosen & Rekhter Standards Track [Page 12]
+
+RFC 4364 BGP/MPLS IP VPNs February 2006
+
+
+4.1. The VPN-IPv4 Address Family
+
+ The BGP Multiprotocol Extensions [BGP-MP] allow BGP to carry routes
+ from multiple "address families". We introduce the notion of the
+ "VPN-IPv4 address family". A VPN-IPv4 address is a 12-byte quantity,
+ beginning with an 8-byte Route Distinguisher (RD) and ending with a
+ 4-byte IPv4 address. If several VPNs use the same IPv4 address
+ prefix, the PEs translate these into unique VPN-IPv4 address
+ prefixes. This ensures that if the same address is used in several
+ different VPNs, it is possible for BGP to carry several completely
+ different routes to that address, one for each VPN.
+
+ Since VPN-IPv4 addresses and IPv4 addresses are different address
+ families, BGP never treats them as comparable addresses.
+
+ An RD is simply a number, and it does not contain any inherent
+ information; it does not identify the origin of the route or the set
+ of VPNs to which the route is to be distributed. The purpose of the
+ RD is solely to allow one to create distinct routes to a common IPv4
+ address prefix. Other means are used to determine where to
+ redistribute the route (see Section 4.3).
+
+ The RD can also be used to create multiple different routes to the
+ very same system. We have already discussed a situation in which the
+ route to a particular server should be different for intranet traffic
+ than for extranet traffic. This can be achieved by creating two
+ different VPN-IPv4 routes that have the same IPv4 part, but different
+ RDs. This allows BGP to install multiple different routes to the
+ same system, and allows policy to be used (see Section 4.3.5) to
+ decide which packets use which route.
+
+ The RDs are structured so that every Service Provider can administer
+ its own "numbering space" (i.e., can make its own assignments of
+ RDs), without conflicting with the RD assignments made by any other
+ Service Provider. An RD consists of three fields: a 2-byte type
+ field, an administrator field, and an assigned number field. The
+ value of the type field determines the lengths of the other two
+ fields, as well as the semantics of the administrator field. The
+ administrator field identifies an assigned number authority, and the
+ assigned number field contains a number that has been assigned, by
+ the identified authority, for a particular purpose. For example, one
+ could have an RD whose administrator field contains an Autonomous
+ System number (ASN), and whose (4-byte) number field contains a
+ number assigned by the SP to whom that ASN belongs (having been
+ assigned to that SP by the appropriate authority).
+
+ RDs are given this structure in order to ensure that an SP that
+ provides VPN backbone service can always create a unique RD when it
+
+
+
+Rosen & Rekhter Standards Track [Page 13]
+
+RFC 4364 BGP/MPLS IP VPNs February 2006
+
+
+ needs to do so. However, the structure is not meaningful to BGP;
+ when BGP compares two such address prefixes, it ignores the structure
+ entirely.
+
+ A PE needs to be configured such that routes that lead to a
+ particular CE become associated with a particular RD. The
+ configuration may cause all routes leading to the same CE to be
+ associated with the same RD, or it may cause different routes to be
+ associated with different RDs, even if they lead to the same CE.
+
+4.2. Encoding of Route Distinguishers
+
+ As stated, a VPN-IPv4 address consists of an 8-byte Route
+ Distinguisher followed by a 4-byte IPv4 address. The RDs are encoded
+ as follows:
+
+ - Type Field: 2 bytes
+ - Value Field: 6 bytes
+
+ The interpretation of the Value field depends on the value of the
+ type field. At the present time, three values of the type field are
+ defined: 0, 1, and 2.
+
+ - Type 0: The Value field consists of two subfields:
+
+ * Administrator subfield: 2 bytes
+ * Assigned Number subfield: 4 bytes
+
+ The Administrator subfield must contain an Autonomous System
+ number. If this ASN is from the public ASN space, it must have
+ been assigned by the appropriate authority (use of ASN values
+ from the private ASN space is strongly discouraged). The
+ Assigned Number subfield contains a number from a numbering space
+ that is administered by the enterprise to which the ASN has been
+ assigned by an appropriate authority.
+
+ - Type 1: The Value field consists of two subfields:
+
+ * Administrator subfield: 4 bytes
+ * Assigned Number subfield: 2 bytes
+
+ The Administrator subfield must contain an IP address. If this
+ IP address is from the public IP address space, it must have been
+ assigned by an appropriate authority (use of addresses from the
+ private IP address space is strongly discouraged). The Assigned
+ Number subfield contains a number from a numbering space which is
+ administered by the enterprise to which the IP address has been
+ assigned.
+
+
+
+Rosen & Rekhter Standards Track [Page 14]
+
+RFC 4364 BGP/MPLS IP VPNs February 2006
+
+
+ - Type 2: The Value field consists of two subfields:
+
+ * Administrator subfield: 4 bytes
+ * Assigned Number subfield: 2 bytes
+
+ The Administrator subfield must contain a 4-byte Autonomous
+ System number [BGP-AS4]. If this ASN is from the public ASN
+ space, it must have been assigned by the appropriate authority
+ (use of ASN values from the private ASN space is strongly
+ discouraged). The Assigned Number subfield contains a number
+ from a numbering space which is administered by the enterprise to
+ which the ASN has been assigned by an appropriate authority.
+
+4.3. Controlling Route Distribution
+
+ In this section, we discuss the way in which the distribution of the
+ VPN-IPv4 routes is controlled.
+
+ If a PE router is attached to a particular VPN (by being attached to
+ a particular CE in that VPN), it learns some of that VPN's IP routes
+ from the attached CE router. Routes learned from a CE routing peer
+ over a particular attachment circuit may be installed in the VRF
+ associated with that attachment circuit. Exactly which routes are
+ installed in this manner is determined by the way in which the PE
+ learns routes from the CE. In particular, when the PE and CE are
+ routing protocol peers, this is determined by the decision process of
+ the routing protocol; this is discussed in Section 7.
+
+ These routes are then converted to VPN-IP4 routes, and "exported" to
+ BGP. If there is more than one route to a particular VPN-IP4 address
+ prefix, BGP chooses the "best" one, using the BGP decision process.
+ That route is then distributed by BGP to the set of other PEs that
+ need to know about it. At these other PEs, BGP will again choose the
+ best route for a particular VPN-IP4 address prefix. Then the chosen
+ VPN-IP4 routes are converted back into IP routes, and "imported" into
+ one or more VRFs. Whether they are actually installed in the VRFs
+ depends on the decision process of the routing method used between
+ the PE and those CEs that are associated with the VRF in question.
+ Finally, any route installed in a VRF may be distributed to the
+ associated CE routers.
+
+4.3.1. The Route Target Attribute
+
+ Every VRF is associated with one or more Route Target (RT)
+ attributes.
+
+ When a VPN-IPv4 route is created (from an IPv4 route that the PE has
+ learned from a CE) by a PE router, it is associated with one or more
+
+
+
+Rosen & Rekhter Standards Track [Page 15]
+
+RFC 4364 BGP/MPLS IP VPNs February 2006
+
+
+ Route Target attributes. These are carried in BGP as attributes of
+ the route.
+
+ Any route associated with Route Target T must be distributed to every
+ PE router that has a VRF associated with Route Target T. When such a
+ route is received by a PE router, it is eligible to be installed in
+ those of the PE's VRFs that are associated with Route Target T.
+ (Whether it actually gets installed depends upon the outcome of the
+ BGP decision process, and upon the outcome of the decision process of
+ the IGP (i.e., the intra-domain routing protocol) running on the
+ PE/CE interface.)
+
+ A Route Target attribute can be thought of as identifying a set of
+ sites. (Though it would be more precise to think of it as
+ identifying a set of VRFs.) Associating a particular Route Target
+ attribute with a route allows that route to be placed in the VRFs
+ that are used for routing traffic that is received from the
+ corresponding sites.
+
+ There is a set of Route Targets that a PE router attaches to a route
+ received from site S; these may be called the "Export Targets". And
+ there is a set of Route Targets that a PE router uses to determine
+ whether a route received from another PE router could be placed in
+ the VRF associated with site S; these may be called the "Import
+ Targets". The two sets are distinct, and need not be the same. Note
+ that a particular VPN-IPv4 route is only eligible for installation in
+ a particular VRF if there is some Route Target that is both one of
+ the route's Route Targets and one of the VRF's Import Targets.
+
+ The function performed by the Route Target attribute is similar to
+ that performed by the BGP Communities attribute. However, the format
+ of the latter is inadequate for present purposes, since it allows
+ only a 2-byte numbering space. It is desirable to structure the
+ format, similar to what we have described for RDs (see Section 4.2),
+ so that a type field defines the length of an administrator field,
+ and the remainder of the attribute is a number from the specified
+ administrator's numbering space. This can be done using BGP Extended
+ Communities. The Route Targets discussed herein are encoded as BGP
+ Extended Community Route Targets [BGP-EXTCOMM]. They are structured
+ similarly to the RDs.
+
+ When a BGP speaker has received more than one route to the same VPN-
+ IPv4 prefix, the BGP rules for route preference are used to choose
+ which VPN-IPv4 route is installed by BGP.
+
+ Note that a route can only have one RD, but it can have multiple
+ Route Targets. In BGP, scalability is improved if one has a single
+ route with multiple attributes, as opposed to multiple routes. One
+
+
+
+Rosen & Rekhter Standards Track [Page 16]
+
+RFC 4364 BGP/MPLS IP VPNs February 2006
+
+
+ could eliminate the Route Target attribute by creating more routes
+ (i.e., using more RDs), but the scaling properties would be less
+ favorable.
+
+ How does a PE determine which Route Target attributes to associate
+ with a given route? There are a number of different possible ways.
+ The PE might be configured to associate all routes that lead to a
+ specified site with a specified Route Target. Or the PE might be
+ configured to associate certain routes leading to a specified site
+ with one Route Target, and certain with another.
+
+ If the PE and the CE are themselves BGP peers (see Section 7), then
+ the SP may allow the customer, within limits, to specify how its
+ routes are to be distributed. The SP and the customer would need to
+ agree in advance on the set of RTs that are allowed to be attached to
+ the customer's VPN routes. The CE could then attach one or more of
+ those RTs to each IP route that it distributes to the PE. This gives
+ the customer the freedom to specify in real time, within agreed-upon
+ limits, its route distribution policies. If the CE is allowed to
+ attach RTs to its routes, the PE MUST filter out all routes that
+ contain RTs that the customer is not allowed to use. If the CE is
+ not allowed to attach RTs to its routes, but does so anyway, the PE
+ MUST remove the RT before converting the customer's route to a VPN-
+ IPv4 route.
+
+4.3.2. Route Distribution Among PEs by BGP
+
+ If two sites of a VPN attach to PEs that are in the same Autonomous
+ System, the PEs can distribute VPN-IPv4 routes to each other by means
+ of an IBGP connection between them. (The term "IBGP" refers to the
+ set of protocols and procedures used when there is a BGP connection
+ between two BGP speakers in the same Autonomous System. This is
+ distinguished from "EBGP", the set of procedures used between two BGP
+ speakers in different Autonomous Systems.) Alternatively, each can
+ have an IBGP connection to a route reflector [BGP-RR].
+
+ When a PE router distributes a VPN-IPv4 route via BGP, it uses its
+ own address as the "BGP next hop". This address is encoded as a
+ VPN-IPv4 address with an RD of 0. ([BGP-MP] requires that the next
+ hop address be in the same address family as the Network Layer
+ Reachability Information (NLRI).) It also assigns and distributes an
+ MPLS label. (Essentially, PE routers distribute not VPN-IPv4 routes,
+ but Labeled VPN-IPv4 routes. Cf. [MPLS-BGP].) When the PE processes
+ a received packet that has this label at the top of the stack, the PE
+ will pop the stack, and process the packet appropriately.
+
+
+
+
+
+
+Rosen & Rekhter Standards Track [Page 17]
+
+RFC 4364 BGP/MPLS IP VPNs February 2006
+
+
+ The PE may distribute the exact set of routes that appears in the
+ VRF, or it may perform summarization and distribute aggregates of
+ those routes, or it may do some of one and some of the other.
+
+ Suppose that a PE has assigned label L to route R, and has
+ distributed this label mapping via BGP. If R is an aggregate of a
+ set of routes in the VRF, the PE will know that packets from the
+ backbone that arrive with this label must have their destination
+ addresses looked up in a VRF. When the PE looks up the label in its
+ Label Information Base, it learns which VRF must be used. On the
+ other hand, if R is not an aggregate, then when the PE looks up the
+ label, it learns the egress attachment circuit, as well as the
+ encapsulation header for the packet. In this case, no lookup in the
+ VRF is done.
+
+ We would expect that the most common case would be the case where the
+ route is NOT an aggregate. The case where it is an aggregate can be
+ very useful though if the VRF contains a large number of host routes
+ (e.g., as in dial-in), or if the VRF has an associated Local Area
+ Network (LAN) interface (where there is a different outgoing layer 2
+ header for each system on the LAN, but a route is not distributed for
+ each such system).
+
+ Whether or not each route has a distinct label is an implementation
+ matter. There are a number of possible algorithms one could use to
+ determine whether two routes get assigned the same label:
+
+ - One may choose to have a single label for an entire VRF, so that
+ a single label is shared by all the routes from that VRF. Then
+ when the egress PE receives a packet with that label, it must
+ look up the packet's IP destination address in that VRF (the
+ packet's "egress VRF"), in order to determine the packet's egress
+ attachment circuit and the corresponding data link encapsulation.
+
+ - One may choose to have a single label for each attachment
+ circuit, so that a single label is shared by all the routes with
+ the same "outgoing attachment circuit". This enables one to
+ avoid doing a lookup in the egress VRF, though some sort of
+ lookup may need to be done in order to determine the data link
+ encapsulation, e.g., an Address Resolution Protocol (ARP) lookup.
+
+ - One may choose to have a distinct label for each route. Then if
+ a route is potentially reachable over more than one attachment
+ circuit, the PE/CE routing can switch the preferred path for a
+ route from one attachment circuit to another, without there being
+ any need to distribute new a label for that route.
+
+
+
+
+
+Rosen & Rekhter Standards Track [Page 18]
+
+RFC 4364 BGP/MPLS IP VPNs February 2006
+
+
+ There may be other possible algorithms as well. The choice of
+ algorithm is entirely at the discretion of the egress PE, and is
+ otherwise transparent.
+
+ In using BGP-distributed MPLS labels in this manner, we presuppose
+ that an MPLS packet carrying such a label can be tunneled from the
+ router that installs the corresponding BGP-distributed route to the
+ router that is the BGP next hop of that route. This requires either
+ that a label switched path exist between those two routers or else
+ that some other tunneling technology (e.g., [MPLS-in-IP-GRE]) can be
+ used between them.
+
+ This tunnel may follow a "best effort" route, or it may follow a
+ traffic-engineered route. Between a given pair of routers, there may
+ be one such tunnel, or there may be several, perhaps with different
+ Quality of Service (QoS) characteristics. All that matters for the
+ VPN architecture is that some such tunnel exists. To ensure
+ interoperability among systems that implement this VPN architecture
+ using MPLS label switched paths as the tunneling technology, all such
+ systems MUST support Label Distribution Protocol (LDP) [MPLS-LDP].
+ In particular, Downstream Unsolicited mode MUST be supported on
+ interfaces that are neither Label Controlled ATM (LC-ATM) [MPLS-ATM]
+ nor Label Controlled Frame Relay (LC-FR) [MPLS-FR] interfaces, and
+ Downstream on Demand mode MUST be supported on LC-ATM interfaces and
+ LC-FR interfaces.
+
+ If the tunnel follows a best-effort route, then the PE finds the
+ route to the remote endpoint by looking up its IP address in the
+ default forwarding table.
+
+ A PE router, UNLESS it is a route reflector (see Section 4.3.3) or an
+ Autonomous System Border Router (ASBR) for an inter-provider VPN (see
+ Section 10), should not install a VPN-IPv4 route unless it has at
+ least one VRF with an Import Target identical to one of the route's
+ Route Target attributes. Inbound filtering should be used to cause
+ such routes to be discarded. If a new Import Target is later added
+ to one of the PE's VRFs (a "VPN Join" operation), it must then
+ acquire the routes it may previously have discarded. This can be
+ done using the refresh mechanism described in [BGP-RFSH]. The
+ outbound route filtering mechanism of [BGP-ORF] can also be used to
+ advantage to make the filtering more dynamic.
+
+ Similarly, if a particular Import Target is no longer present in any
+ of a PE's VRFs (as a result of one or more "VPN Prune" operations),
+ the PE may discard all routes that, as a result, no longer have any
+ of the PE's VRF's Import Targets as one of their Route Target
+ attributes.
+
+
+
+
+Rosen & Rekhter Standards Track [Page 19]
+
+RFC 4364 BGP/MPLS IP VPNs February 2006
+
+
+ A router that is not attached to any VPN and that is not a Route
+ Reflector (i.e., a P router) never installs any VPN-IPv4 routes at
+ all.
+
+ Note that VPN Join and Prune operations are non-disruptive and do not
+ require any BGP connections to be brought down, as long as the
+ refresh mechanism of [BGP-RFSH] is used.
+
+ As a result of these distribution rules, no one PE ever needs to
+ maintain all routes for all VPNs; this is an important scalability
+ consideration.
+
+4.3.3. Use of Route Reflectors
+
+ Rather than having a complete IBGP mesh among the PEs, it is
+ advantageous to make use of BGP Route Reflectors [BGP-RR] to improve
+ scalability. All the usual techniques for using route reflectors to
+ improve scalability (e.g., route reflector hierarchies) are
+ available.
+
+ Route reflectors are the only systems that need to have routing
+ information for VPNs to which they are not directly attached.
+ However, there is no need to have any one route reflector know all
+ the VPN-IPv4 routes for all the VPNs supported by the backbone.
+
+ We outline below two different ways to partition the set of VPN-IPv4
+ routes among a set of route reflectors.
+
+ 1. Each route reflector is preconfigured with a list of Route
+ Targets. For redundancy, more than one route reflector may be
+ preconfigured with the same list. A route reflector uses the
+ preconfigured list of Route Targets to construct its inbound
+ route filtering. The route reflector may use the techniques of
+ [BGP-ORF] to install on each of its peers (regardless of
+ whether the peer is another route reflector or a PE) the set of
+ Outbound Route Filters (ORFs) that contains the list of its
+ preconfigured Route Targets. Note that route reflectors should
+ accept ORFs from other route reflectors, which means that route
+ reflectors should advertise the ORF capability to other route
+ reflectors.
+
+ A service provider may modify the list of preconfigured Route
+ Targets on a route reflector. When this is done, the route
+ reflector modifies the ORFs it installs on all of its IBGP
+ peers. To reduce the frequency of configuration changes on
+ route reflectors, each route reflector may be preconfigured
+ with a block of Route Targets. This way, when a new Route
+ Target is needed for a new VPN, there is already one or more
+
+
+
+Rosen & Rekhter Standards Track [Page 20]
+
+RFC 4364 BGP/MPLS IP VPNs February 2006
+
+
+ route reflectors that are (pre)configured with this Route
+ Target.
+
+ Unless a given PE is a client of all route reflectors, when a
+ new VPN is added to the PE ("VPN Join"), it will need to become
+ a client of the route reflector(s) that maintain routes for
+ that VPN. Likewise, deleting an existing VPN from the PE ("VPN
+ Prune") may result in a situation where the PE no longer needs
+ to be a client of some route reflector(s). In either case, the
+ Join or Prune operation is non-disruptive (as long as
+ [BGP-RFSH] is used, and never requires a BGP connection to be
+ brought down, only to be brought right back up.
+
+ (By "adding a new VPN to a PE", we really mean adding a new
+ import Route Target to one of its VRFs, or adding a new VRF
+ with an import Route Target not had by any of the PE's other
+ VRFs.)
+
+ 2. Another method is to have each PE be a client of some subset of
+ the route reflectors. A route reflector is not preconfigured
+ with the list of Route Targets, and does not perform inbound
+ route filtering of routes received from its clients (PEs);
+ rather, it accepts all the routes received from all of its
+ clients (PEs). The route reflector keeps track of the set of
+ the Route Targets carried by all the routes it receives. When
+ the route reflector receives from its client a route with a
+ Route Target that is not in this set, this Route Target is
+ immediately added to the set. On the other hand, when the
+ route reflector no longer has any routes with a particular
+ Route Target that is in the set, the route reflector should
+ delay (by a few hours) the deletion of this Route Target from
+ the set.
+
+ The route reflector uses this set to form the inbound route
+ filters that it applies to routes received from other route
+ reflectors. The route reflector may also use ORFs to install
+ the appropriate outbound route filtering on other route
+ reflectors. Just like with the first approach, a route
+ reflector should accept ORFs from other route reflectors. To
+ accomplish this, a route reflector advertises ORF capability to
+ other route reflectors.
+
+ When the route reflector changes the set, it should immediately
+ change its inbound route filtering. In addition, if the route
+ reflector uses ORFs, then the ORFs have to be immediately
+ changed to reflect the changes in the set. If the route
+ reflector doesn't use ORFs, and a new Route Target is added to
+
+
+
+
+Rosen & Rekhter Standards Track [Page 21]
+
+RFC 4364 BGP/MPLS IP VPNs February 2006
+
+
+ the set, the route reflector, after changing its inbound route
+ filtering, must issue BGP Refresh to other route reflectors.
+
+ The delay of "a few hours" mentioned above allows a route
+ reflector to hold onto routes with a given RT, even after it
+ loses the last of its clients that are interested in such
+ routes. This protects against the need to reacquire all such
+ routes if the clients' "disappearance" is only temporary.
+
+ With this procedure, VPN Join and Prune operations are also
+ non-disruptive.
+
+ Note that this technique will not work properly if some client
+ PE has a VRF with an import Route Target that is not one of its
+ export Route Targets.
+
+ In these procedures, a PE router which attaches to a particular VPN
+ "auto-discovers" the other PEs that attach to the same VPN. When a
+ new PE router is added, or when an existing PE router attaches to a
+ new VPN, no reconfiguration of other PE routers is needed.
+
+ Just as there is no one PE router that needs to know all the VPN-IPv4
+ routes supported over the backbone, these distribution rules ensure
+ that there is no one Route Reflector (RR) that needs to know all the
+ VPN-IPv4 routes supported over the backbone. As a result, the total
+ number of such routes that can be supported over the backbone is not
+ bounded by the capacity of any single device, and therefore can
+ increase virtually without bound.
+
+4.3.4. How VPN-IPv4 NLRI Is Carried in BGP
+
+ The BGP Multiprotocol Extensions [BGP-MP] are used to encode the
+ NLRI. If the Address Family Identifier (AFI) field is set to 1, and
+ the Subsequent Address Family Identifier (SAFI) field is set to 128,
+ the NLRI is an MPLS-labeled VPN-IPv4 address. AFI 1 is used since
+ the network layer protocol associated with the NLRI is still IP.
+ Note that this VPN architecture does not require the capability to
+ distribute unlabeled VPN-IPv4 addresses.
+
+ In order for two BGP speakers to exchange labeled VPN-IPv4 NLRI, they
+ must use BGP Capabilities Advertisement to ensure that they both are
+ capable of properly processing such NLRI. This is done as specified
+ in [BGP-MP], by using capability code 1 (multiprotocol BGP), with an
+ AFI of 1 and an SAFI of 128.
+
+ The labeled VPN-IPv4 NLRI itself is encoded as specified in
+ [MPLS-BGP], where the prefix consists of an 8-byte RD followed by an
+ IPv4 prefix.
+
+
+
+Rosen & Rekhter Standards Track [Page 22]
+
+RFC 4364 BGP/MPLS IP VPNs February 2006
+
+
+4.3.5. Building VPNs Using Route Targets
+
+ By setting up the Import Targets and Export Targets properly, one can
+ construct different kinds of VPNs.
+
+ Suppose it is desired to create a fully meshed closed user group,
+ i.e., a set of sites where each can send traffic directly to the
+ other, but traffic cannot be sent to or received from other sites.
+ Then each site is associated with a VRF, a single Route Target
+ attribute is chosen, that Route Target is assigned to each VRF as
+ both the Import Target and the Export Target, and that Route Target
+ is not assigned to any other VRFs as either the Import Target or the
+ Export Target.
+
+ Alternatively, suppose one desired, for whatever reason, to create a
+ "hub and spoke" kind of VPN. This could be done by the use of two
+ Route Target values, one meaning "Hub" and one meaning "Spoke". At
+ the VRFs attached to the hub sites, "Hub" is the Export Target and
+
+ "Spoke" is the Import Target. At the VRFs attached to the spoke
+ site, "Hub" is the Import Target and "Spoke" is the Export Target.
+
+ Thus, the methods for controlling the distribution of routing
+ information among various sets of sites are very flexible, which in
+ turn provides great flexibility in constructing VPNs.
+
+4.3.6. Route Distribution Among VRFs in a Single PE
+
+ It is possible to distribute routes from one VRF to another, even if
+ both VRFs are in the same PE, even though in this case one cannot say
+ that the route has been distributed by BGP. Nevertheless, the
+ decision to distribute a particular route from one VRF to another
+ within a single PE is the same decision that would be made if the
+ VRFs were on different PEs. That is, it depends on the Route Target
+ attribute that is assigned to the route (or would be assigned if the
+ route were distributed by BGP), and the import target of the second
+ VRF.
+
+5. Forwarding
+
+ If the intermediate routers in the backbone do not have any
+ information about the routes to the VPNs, how are packets forwarded
+ from one VPN site to another?
+
+ When a PE receives an IP packet from a CE device, it chooses a
+ particular VRF in which to look up the packet's destination address.
+ This choice is based on the packet's ingress attachment circuit.
+
+
+
+
+Rosen & Rekhter Standards Track [Page 23]
+
+RFC 4364 BGP/MPLS IP VPNs February 2006
+
+
+ Assume that a match is found. As a result we learn the packet's
+ "next hop".
+
+ If the packet's next hop is reached directly over a VRF attachment
+ circuit from this PE (i.e., the packet's egress attachment circuit is
+ on the same PE as its ingress attachment circuit), then the packet is
+ sent on the egress attachment circuit, and no MPLS labels are pushed
+ onto the packet's label stack.
+
+ If the ingress and egress attachment circuits are on the same PE, but
+ are associated with different VRFs, and if the route that best
+ matches the destination address in the ingress attachment circuit's
+ VRF is an aggregate of several routes in the egress attachment
+ circuit's VRF, it may be necessary to look up the packet's
+ destination address in the egress VRF as well.
+
+ If the packet's next hop is NOT reached through a VRF attachment
+ circuit, then the packet must travel at least one hop through the
+ backbone. The packet thus has a "BGP Next Hop", and the BGP Next Hop
+ will have assigned an MPLS label for the route that best matches the
+ packet's destination address. Call this label the "VPN route label".
+ The IP packet is turned into an MPLS packet with the VPN route label
+ as the sole label on the label stack.
+
+ The packet must then be tunneled to the BGP Next Hop.
+
+ If the backbone supports MPLS, this is done as follows:
+
+ - The PE routers (and any Autonomous System border routers) that
+ redistribute VPN-IPv4 addresses need to insert /32 address
+ prefixes for themselves into the IGP routing tables of the
+ backbone. This enables MPLS, at each node in the backbone
+ network, to assign a label corresponding to the route to each PE
+ router. To ensure interoperability among different
+ implementations, it is required to support LDP for setting up the
+ label switched paths across the backbone. However, other methods
+ of setting up these label switched paths are also possible.
+ (Some of these other methods may not require the presence of the
+ /32 address prefixes in the IGP.)
+
+ - If there are any traffic engineering tunnels to the BGP next hop,
+ and if one or more of those is available for use by the packet in
+ question, one of these tunnels is chosen. This tunnel will be
+ associated with an MPLS label, the "tunnel label". The tunnel
+ label gets pushed on the MPLS label stack, and the packet is
+ forwarded to the tunnel's next hop.
+
+
+
+
+
+Rosen & Rekhter Standards Track [Page 24]
+
+RFC 4364 BGP/MPLS IP VPNs February 2006
+
+
+ - Otherwise,
+
+ * The packet will have an "IGP Next Hop", which is the next hop
+ along the IGP route to the BGP Next Hop.
+
+ * If the BGP Next Hop and the IGP Next Hop are the same, and if
+ penultimate hop popping is used, the packet is then sent to
+ the IGP Next Hop, carrying only the VPN route label.
+
+ * Otherwise, the IGP Next Hop will have assigned a label for
+ the route that best matches the address of the BGP Next Hop.
+ Call this the "tunnel label". The tunnel label gets pushed
+ on as the packet's top label. The packet is then forwarded
+ to the IGP Next Hop.
+
+ - MPLS will then carry the packet across the backbone to the BGP
+ Next Hop, where the VPN label will be examined.
+
+ If the backbone does not support MPLS, the MPLS packet carrying only
+ the VPN route label may be tunneled to the BGP Next Hop using the
+ techniques of [MPLS-in-IP-GRE]. When the packet emerges from the
+ tunnel, it will be at the BGP Next Hop, where the VPN route label
+ will be examined.
+
+ At the BGP Next Hop, the treatment of the packet depends on the VPN
+ route label (see Section 4.3.2). In many cases, the PE will be able
+ to determine, from this label, the attachment circuit over which the
+ packet should be transmitted (to a CE device), as well as the proper
+ data link layer header for that interface. In other cases, the PE
+ may only be able to determine that the packet's destination address
+ needs to be looked up in a particular VRF before being forwarded to a
+ CE device. There are also intermediate cases in which the VPN route
+ label may determine the packet's egress attachment circuit, but a
+ lookup (e.g., ARP) still needs to be done in order to determine the
+ packet's data link header on that attachment circuit.
+
+ Information in the MPLS header itself, and/or information associated
+ with the label, may also be used to provide QoS on the interface to
+ the CE.
+
+ In any event, if the packet was an unlabeled IP packet when it
+ arrived at its ingress PE, it will again be an unlabeled packet when
+ it leaves its egress PE.
+
+ The fact that packets with VPN route labels are tunneled through the
+ backbone is what makes it possible to keep all the VPN routes out of
+ the P routers. This is crucial to ensuring the scalability of the
+
+
+
+
+Rosen & Rekhter Standards Track [Page 25]
+
+RFC 4364 BGP/MPLS IP VPNs February 2006
+
+
+ scheme. The backbone does not even need to have routes to the CEs,
+ only to the PEs.
+
+ With respect to the tunnels, it is worth noting that this
+ specification:
+
+ - DOES NOT require that the tunnels be point-to-point; multipoint-
+ to-point can be used;
+
+ - DOES NOT require that there be any explicit setup of the tunnels,
+ either via signaling or via manual configuration;
+
+ - DOES NOT require that there be any tunnel-specific signaling;
+
+ - DOES NOT require that there be any tunnel-specific state in the P
+ or PE routers, beyond what is necessary to maintain the routing
+ information and (if used) the MPLS label information.
+
+ Of course, this specification is compatible with the use of point-
+ to-point tunnels that must be explicitly configured and/or signaled,
+ and in some situations there may be reasons for using such tunnels.
+
+ The considerations that are relevant to choosing a particular
+ tunneling technology are outside the scope of this specification.
+
+6. Maintaining Proper Isolation of VPNs
+
+ To maintain proper isolation of one VPN from another, it is important
+ that no router in the backbone accept a tunneled packet from outside
+ the backbone, unless it is sure that both endpoints of that tunnel
+ are outside the backbone.
+
+ If MPLS is being used as the tunneling technology, this means that a
+ router in the backbone MUST NOT accept a labeled packet from any
+ adjacent non-backbone device unless the following two conditions
+ hold:
+
+ 1. the label at the top of the label stack was actually
+ distributed by that backbone router to that non-backbone
+ device, and
+
+ 2. the backbone router can determine that use of that label will
+ cause the packet to leave the backbone before any labels lower
+ in the stack will be inspected, and before the IP header will
+ be inspected.
+
+ The first condition ensure that any labeled packets received from
+ non-backbone routers have a legitimate and properly assigned label at
+
+
+
+Rosen & Rekhter Standards Track [Page 26]
+
+RFC 4364 BGP/MPLS IP VPNs February 2006
+
+
+ the top of the label stack. The second condition ensures that the
+ backbone routers will never look below that top label. Of course,
+ the simplest way to meet these two conditions is just to have the
+ backbone devices refuse to accept labeled packets from non-backbone
+ devices.
+
+ If MPLS is not being used as the tunneling technology, then filtering
+ must be done to ensure that an MPLS-in-IP or MPLS-in-GRE packet can
+ be accepted into the backbone only if the packet's IP destination
+ address will cause it to be sent outside the backbone.
+
+7. How PEs Learn Routes from CEs
+
+ The PE routers that attach to a particular VPN need to know, for each
+ attachment circuit leading to that VPN, which of the VPN's addresses
+ should be reached over that attachment circuit.
+
+ The PE translates these addresses into VPN-IPv4 addresses, using a
+ configured RD. The PE then treats these VPN-IPv4 routes as input to
+ BGP. Routes from a VPN site are NOT leaked into the backbone's IGP.
+
+ Exactly which PE/CE route distribution techniques are possible
+ depends on whether or not a particular CE is in a "transit VPN". A
+ "transit VPN" is one that contains a router that receives routes from
+ a "third party" (i.e., from a router that is not in the VPN, but is
+ not a PE router) and that redistributes those routes to a PE router.
+ A VPN that is not a transit VPN is a "stub VPN". The vast majority
+ of VPNs, including just about all corporate enterprise networks,
+ would be expected to be "stubs" in this sense.
+
+ The possible PE/CE distribution techniques are:
+
+ 1. Static routing (i.e., configuration) may be used. (This is
+ likely to be useful only in stub VPNs.)
+
+ 2. PE and CE routers may be Routing Information Protocol (RIP)
+ [RIP] peers, and the CE may use RIP to tell the PE router the
+ set of address prefixes that are reachable at the CE router's
+ site. When RIP is configured in the CE, care must be taken to
+ ensure that address prefixes from other sites (i.e., address
+ prefixes learned by the CE router from the PE router) are never
+ advertised to the PE. More precisely: if a PE router, say,
+ PE1, receives a VPN-IPv4 route R1, and as a result distributes
+ an IPv4 route R2 to a CE, then R2 must not be distributed back
+ from that CE's site to a PE router, say, PE2, (where PE1 and
+ PE2 may be the same router or different routers), unless PE2
+ maps R2 to a VPN-IPv4 route that is different than (i.e.,
+ contains a different RD than) R1.
+
+
+
+Rosen & Rekhter Standards Track [Page 27]
+
+RFC 4364 BGP/MPLS IP VPNs February 2006
+
+
+ 3. The PE and CE routers may be OSPF peers. A PE router that is
+ an OSPF peer of a CE router appears, to the CE router, to be an
+ area 0 router. If a PE router is an OSPF peer of CE routers
+ that are in distinct VPNs, the PE must of course be running
+ multiple instances of OSPF.
+
+ IPv4 routes that the PE learns from the CE via OSPF are
+ redistributed into BGP as VPN-IPv4 routes. Extended Community
+ attributes are used to carry, along with the route, all the
+ information needed to enable the route to be distributed to
+ other CE routers in the VPN in the proper type of OSPF Link
+ State Advertisement (LSA). OSPF route tagging is used to
+ ensure that routes received from the MPLS/BGP backbone are not
+ sent back into the backbone.
+
+ Specification of the complete set of procedures for the use of
+ OSPF between PE and CE can be found in [VPN-OSPF] and
+ [OSPF-2547-DNBIT].
+
+ 4. The PE and CE routers may be BGP peers, and the CE router may
+ use BGP (in particular, EBGP to tell the PE router the set of
+ address prefixes that are at the CE router's site. (This
+ technique can be used in stub VPNs or transit VPNs.)
+
+ This technique has a number of advantages over the others:
+
+ a) Unlike the IGP alternatives, this does not require the PE
+ to run multiple routing algorithm instances in order to
+ talk to multiple CEs.
+
+ b) BGP is explicitly designed for just this function:
+ passing routing information between systems run by
+ different administrations.
+
+ c) If the site contains "BGP backdoors", i.e., routers with
+ BGP connections to routers other than PE routers, this
+ procedure will work correctly in all circumstances. The
+ other procedures may or may not work, depending on the
+ precise circumstances.
+
+ d) Use of BGP makes it easy for the CE to pass attributes of
+ the routes to the PE. A complete specification of the
+ set of attributes and their use is outside the scope of
+ this document. However, some examples of the way this
+ may be used are the following:
+
+
+
+
+
+
+Rosen & Rekhter Standards Track [Page 28]
+
+RFC 4364 BGP/MPLS IP VPNs February 2006
+
+
+ - The CE may suggest a particular Route Target for each
+ route, from among the Route Targets that the PE is
+ authorized to attach to the route. The PE would then
+ attach only the suggested Route Target, rather than
+ the full set. This gives the CE administrator some
+ dynamic control of the distribution of routes from
+ the CE.
+
+ - Additional types of Extended Community attributes may
+ be defined, where the intention is to have those
+ attributes passed transparently (i.e., without being
+ changed by the PE routers) from CE to CE. This would
+ allow CE administrators to implement additional route
+ filtering, beyond that which is done by the PEs.
+ This additional filtering would not require
+ coordination with the SP.
+
+ On the other hand, using BGP may be something new for the CE
+ administrators.
+
+ If a site is not in a transit VPN, note that it need not have a
+ unique Autonomous System Number (ASN). Every CE whose site is
+ not in a transit VPN can use the same ASN. This can be chosen
+ from the private ASN space, and it will be stripped out by the
+ PE. Routing loops are prevented by use of the Site of Origin
+ attribute (see below).
+
+ What if a set of sites constitutes a transit VPN? This will
+ generally be the case only if the VPN is itself an Internet
+ Service Provider's (ISP's) network, where the ISP is itself
+ buying backbone services from another SP. The latter SP may be
+ called a "carrier's carrier". In this case, the best way to
+ provide the VPN is to have the CE routers support MPLS, and to
+ use the technique described in Section 9.
+
+ When we do not need to distinguish among the different ways in which
+ a PE can be informed of the address prefixes that exist at a given
+ site, we will simply say that the PE has "learned" the routes from
+ that site. This includes the case where the PE has been manually
+ configured with the routes.
+
+ Before a PE can redistribute a VPN-IPv4 route learned from a site, it
+ must assign a Route Target attribute (see Section 4.3.1) to the
+ route, and it may assign a Site of Origin attribute to the route.
+
+ The Site of Origin attribute, if used, is encoded as a Route Origin
+ Extended Community [BGP-EXTCOMM]. The purpose of this attribute is
+ to uniquely identify the set of routes learned from a particular
+
+
+
+Rosen & Rekhter Standards Track [Page 29]
+
+RFC 4364 BGP/MPLS IP VPNs February 2006
+
+
+ site. This attribute is needed in some cases to ensure that a route
+ learned from a particular site via a particular PE/CE connection is
+ not distributed back to the site through a different PE/CE
+ connection. It is particularly useful if BGP is being used as the
+ PE/CE protocol, but different sites have not been assigned distinct
+ ASNs.
+
+8. How CEs Learn Routes from PEs
+
+ In this section, we assume that the CE device is a router.
+
+ If the PE places a particular route in the VRF it uses to route
+ packets received from a particular CE, then in general, the PE may
+ distribute that route to the CE. Of course, the PE may distribute
+ that route to the CE only if this is permitted by the rules of the
+ PE/CE protocol. (For example, if a particular PE/CE protocol has
+ "split horizon", certain routes in the VRF cannot be redistributed
+ back to the CE.) We add one more restriction on the distribution of
+ routes from PE to CE: if a route's Site of Origin attribute
+ identifies a particular site, that route must never be redistributed
+ to any CE at that site.
+
+ In most cases, however, it will be sufficient for the PE to simply
+ distribute the default route to the CE. (In some cases, it may even
+ be sufficient for the CE to be configured with a default route
+ pointing to the PE.) This will generally work at any site that does
+ not itself need to distribute the default route to other sites.
+ (E.g., if one site in a corporate VPN has the corporation's access to
+ the Internet, that site might need to have default distributed to the
+ other site, but one could not distribute default to that site
+ itself.)
+
+ Whatever procedure is used to distribute routes from CE to PE will
+ also be used to distribute routes from PE to CE.
+
+9. Carriers' Carriers
+
+ Sometimes a VPN may actually be the network of an ISP, with its own
+ peering and routing policies. Sometimes a VPN may be the network of
+ an SP that is offering VPN services in turn to its own customers.
+ VPNs like these can also obtain backbone service from another SP, the
+ "carrier's carrier", using essentially the same methods described in
+ this document. However, it is necessary in these cases that the CE
+ routers support MPLS. In particular:
+
+ - The CE routers should distribute to the PE routers ONLY those
+ routes that are internal to the VPN. This allows the VPN to be
+ handled as a stub VPN.
+
+
+
+Rosen & Rekhter Standards Track [Page 30]
+
+RFC 4364 BGP/MPLS IP VPNs February 2006
+
+
+ - The CE routers should support MPLS, in that they should be able
+ to receive labels from the PE routers, and send labeled packets
+ to the PE routers. They do not need to distribute labels of
+ their own, though.
+
+ - The PE routers should distribute, to the CE routers, labels for
+ the routes they distribute to the CE routers.
+
+ The PE must not distribute the same label to two different CEs
+ unless one of the following conditions holds:
+
+ * The two CEs are associated with exactly the same set of VRFs;
+
+ * The PE maintains a different Incoming Label Map ([MPLS-ARCH])
+ for each CE.
+
+ Further, when the PE receives a labeled packet from a CE, it must
+ verify that the top label is one that was distributed to that CE.
+
+ - Routers at the different sites should establish BGP connections
+ among themselves for the purpose of exchanging external routes
+ (i.e., routes that lead outside of the VPN).
+
+ - All the external routes must be known to the CE routers.
+
+ Then when a CE router looks up a packet's destination address, the
+ routing lookup will resolve to an internal address, usually the
+ address of the packet's BGP next hop. The CE labels the packet
+ appropriately and sends the packet to the PE. The PE, rather than
+ looking up the packet's IP destination address in a VRF, uses the
+ packet's top MPLS label to select the BGP next hop. As a result, if
+ the BGP next hop is more than one hop away, the top label will be
+ replaced by two labels, a tunnel label and a VPN route label. If the
+ BGP next hop is one hop away, the top label may be replaced by just
+ the VPN route label. If the ingress PE is also the egress PE, the
+ top label will just be popped. When the packet is sent from its
+ egress PE to a CE, the packet will have one fewer MPLS labels than it
+ had when it was first received by its ingress PE.
+
+ In the above procedure, the CE routers are the only routers in the
+ VPN that need to support MPLS. If, on the other hand, all the
+ routers at a particular VPN site support MPLS, then it is no longer
+ required that the CE routers know all the external routes. All that
+ is required is that the external routes be known to whatever routers
+ are responsible for putting the label stack on a hitherto unlabeled
+ packet and that there be label switched path that leads from those
+ routers to their BGP peers at other sites. In this case, for each
+
+
+
+
+Rosen & Rekhter Standards Track [Page 31]
+
+RFC 4364 BGP/MPLS IP VPNs February 2006
+
+
+ internal route that a CE router distributes to a PE router, it must
+ also distribute a label.
+
+10. Multi-AS Backbones
+
+ What if two sites of a VPN are connected to different Autonomous
+ Systems (e.g., because the sites are connected to different SPs)?
+ The PE routers attached to that VPN will then not be able to maintain
+ IBGP connections with each other, or with a common route reflector.
+ Rather, there needs to be some way to use EBGP to distribute VPN-IPv4
+ addresses.
+
+ There are a number of different ways of handling this case, which we
+ present in order of increasing scalability.
+
+ a) VRF-to-VRF connections at the AS (Autonomous System) border
+ routers.
+
+ In this procedure, a PE router in one AS attaches directly to a
+ PE router in another. The two PE routers will be attached by
+ multiple sub-interfaces, at least one for each of the VPNs
+ whose routes need to be passed from AS to AS. Each PE will
+ treat the other as if it were a CE router. That is, the PEs
+ associate each such sub-interface with a VRF, and use EBGP to
+ distribute unlabeled IPv4 addresses to each other.
+
+ This is a procedure that "just works", and that does not
+ require MPLS at the border between ASes. However, it does not
+ scale as well as the other procedures discussed below.
+
+ b) EBGP redistribution of labeled VPN-IPv4 routes from AS to
+ neighboring AS.
+
+ In this procedure, the PE routers use IBGP to redistribute
+ labeled VPN-IPv4 routes either to an Autonomous System Border
+ Router (ASBR), or to a route reflector of which an ASBR is a
+ client. The ASBR then uses EBGP to redistribute those labeled
+ VPN-IPv4 routes to an ASBR in another AS, which in turn
+ distributes them to the PE routers in that AS, or perhaps to
+ another ASBR which in turn distributes them, and so on.
+
+ When using this procedure, VPN-IPv4 routes should only be
+ accepted on EBGP connections at private peering points, as part
+ of a trusted arrangement between SPs. VPN-IPv4 routes should
+ neither be distributed to nor accepted from the public
+ Internet, or from any BGP peers that are not trusted. An ASBR
+ should never accept a labeled packet from an EBGP peer unless
+ it has actually distributed the top label to that peer.
+
+
+
+Rosen & Rekhter Standards Track [Page 32]
+
+RFC 4364 BGP/MPLS IP VPNs February 2006
+
+
+ If there are many VPNs having sites attached to different
+ Autonomous Systems, there does not need to be a single ASBR
+ between those two ASes that holds all the routes for all the
+ VPNs; there can be multiple ASBRs, each of which holds only the
+ routes for a particular subset of the VPNs.
+
+ This procedure requires that there be a label switched path
+ leading from a packet's ingress PE to its egress PE. Hence the
+ appropriate trust relationships must exist between and among
+ the set of ASes along the path. Also, there must be agreement
+ among the set of SPs as to which border routers need to receive
+ routes with which Route Targets.
+
+ c) Multi-hop EBGP redistribution of labeled VPN-IPv4 routes
+ between source and destination ASes, with EBGP redistribution
+ of labeled IPv4 routes from AS to neighboring AS.
+
+ In this procedure, VPN-IPv4 routes are neither maintained nor
+ distributed by the ASBRs. An ASBR must maintain labeled IPv4
+ /32 routes to the PE routers within its AS. It uses EBGP to
+ distribute these routes to other ASes. ASBRs in any transit
+ ASes will also have to use EBGP to pass along the labeled /32
+ routes. This results in the creation of a label switched path
+ from the ingress PE router to the egress PE router. Now PE
+ routers in different ASes can establish multi-hop EBGP
+ connections to each other, and can exchange VPN-IPv4 routes
+ over those connections.
+
+ If the /32 routes for the PE routers are made known to the P
+ routers of each AS, everything works normally. If the /32
+ routes for the PE routers are NOT made known to the P routers
+ (other than the ASBRs), then this procedure requires a packet's
+ ingress PE to put a three-label stack on it. The bottom label
+ is assigned by the egress PE, corresponding to the packet's
+ destination address in a particular VRF. The middle label is
+ assigned by the ASBR, corresponding to the /32 route to the
+ egress PE. The top label is assigned by the ingress PE's IGP
+ Next Hop, corresponding to the /32 route to the ASBR.
+
+ To improve scalability, one can have the multi-hop EBGP
+ connections exist only between a route reflector in one AS and
+ a route reflector in another. (However, when the route
+ reflectors distribute routes over this connection, they do not
+ modify the BGP next hop attribute of the routes.) The actual
+ PE routers would then only have IBGP connections to the route
+ reflectors in their own AS.
+
+
+
+
+
+Rosen & Rekhter Standards Track [Page 33]
+
+RFC 4364 BGP/MPLS IP VPNs February 2006
+
+
+ This procedure is very similar to the "carrier's carrier"
+ procedures described in Section 9. Like the previous
+ procedure, it requires that there be a label switched path
+ leading from a packet's ingress PE to its egress PE.
+
+11. Accessing the Internet from a VPN
+
+ Many VPN sites will need to be able to access the public Internet, as
+ well as to access other VPN sites. The following describes some of
+ the alternative ways of doing this.
+
+ 1. In some VPNs, one or more of the sites will obtain Internet
+ access by means of an "Internet gateway" (perhaps a firewall)
+ attached to a non-VRF interface to an ISP. The ISP may or may
+ not be the same organization as the SP that is providing the
+ VPN service. Traffic to/from the Internet gateway would then
+ be routed according to the PE router's default forwarding
+ table.
+
+ In this case, the sites that have Internet access may be
+ distributing a default route to their PEs, which in turn
+ redistribute it to other PEs and hence into other sites of the
+ VPN. This provides Internet access for all of the VPN's sites.
+
+ In order to properly handle traffic from the Internet, the ISP
+ must distribute, to the Internet, routes leading to addresses
+ that are within the VPN. This is completely independent of any
+ of the route distribution procedures described in this
+ document. The internal structure of the VPN will in general
+ not be visible from the Internet; such routes would simply lead
+ to the non-VRF interface that attaches to the VPN's Internet
+ gateway.
+
+ In this model, there is no exchange of routes between a PE
+ router's default forwarding table and any of its VRFs. VPN
+ route distribution procedures and Internet route distribution
+ procedures are completely independent.
+
+ Note that although some sites of the VPN use a VRF interface to
+ communicate with the Internet, ultimately all packets to/from
+ the Internet traverse a non-VRF interface before
+ leaving/entering the VPN, so we refer to this as "non-VRF
+ Internet access".
+
+ Note that the PE router to which the non-VRF interface attaches
+ does not necessarily need to maintain all the Internet routes
+ in its default forwarding table. The default forwarding table
+ could have as few as one route, "default", which leads to
+
+
+
+Rosen & Rekhter Standards Track [Page 34]
+
+RFC 4364 BGP/MPLS IP VPNs February 2006
+
+
+ another router (probably an adjacent one) that has the Internet
+ routes. A variation of this scheme is to tunnel packets
+ received over the non-VRF interface from the PE router to
+ another router, where this other router maintains the full set
+ of Internet routes.
+
+ 2. Some VPNs may obtain Internet access via a VRF interface ("VRF
+ Internet access"). If a packet is received by a PE over a VRF
+ interface, and if the packet's destination address does not
+ match any route in the VRF, then it may be matched against the
+ PE's default forwarding table. If a match is made there, the
+ packet can be forwarded natively through the backbone to the
+ Internet, instead of being forwarded by MPLS.
+
+ In order for traffic to flow natively in the opposite direction
+ (from Internet to VRF interface), some of the routes from the
+ VRF must be exported to the Internet forwarding table.
+ Needless to say, any such routes must correspond to globally
+ unique addresses.
+
+ In this scheme, the default forwarding table might have the
+ full set of Internet routes, or it might have as little as a
+ single default route leading to another router that does have
+ the full set of Internet routes in its default forwarding
+ table.
+
+ 3. Suppose the PE has the capability to store "non-VPN routes" in
+ a VRF. If a packet's destination address matches a "non-VPN
+ route", then the packet is transmitted natively, rather than
+ being transmitted via MPLS. If the VRF contains a non-VPN
+ default route, all packets for the public Internet will match
+ it, and be forwarded natively to the default route's next hop.
+ At that next hop, the packets' destination addresses will be
+ looked up in the default forwarding table, and may match more
+ specific routes.
+
+ This technique would only be available if none of the CE
+ routers is distributing a default route.
+
+ 4. It is also possible to obtain Internet access via a VRF
+ interface by having the VRF contain the Internet routes.
+ Compared with model 2, this eliminates the second lookup, but
+ it has the disadvantage of requiring the Internet routes to be
+ replicated in each such VRF.
+
+ If this technique is used, the SP may want to make its
+ interface to the Internet be a VRF interface, and to use the
+
+
+
+
+Rosen & Rekhter Standards Track [Page 35]
+
+RFC 4364 BGP/MPLS IP VPNs February 2006
+
+
+ techniques of Section 4 to distribute Internet routes, as VPN-
+ IPv4 routes, to other VRFs.
+
+ It should be clearly understood that by default, there is no exchange
+ of routes between a VRF and the default forwarding table. This is
+ done ONLY upon agreement between a customer and an SP, and only if it
+ suits the customer's policies.
+
+12. Management VPNs
+
+ This specification does not require that the sub-interface connecting
+ a PE router and a CE router be a "numbered" interface. If it is a
+ numbered interface, this specification allows the addresses assigned
+ to the interface to come from either the address space of the VPN or
+ the address space of the SP.
+
+ If a CE router is being managed by the Service Provider, then the
+ Service Provider will likely have a network management system that
+ needs to be able to communicate with the CE router. In this case,
+ the addresses assigned to the sub-interface connecting the CE and PE
+ routers should come from the SP's address space, and should be unique
+ within that space. The network management system should itself
+ connect to a PE router (more precisely, be at a site that connects to
+ a PE router) via a VRF interface. The address of the network
+ management system will be exported to all VRFs that are associated
+ with interfaces to CE routers that are managed by the SP. The
+ addresses of the CE routers will be exported to the VRF associated
+ with the network management system, but not to any other VRFs.
+
+ This allows communication between the CE and network management
+ system, but does not allow any undesired communication to or among
+ the CE routers.
+
+ One way to ensure that the proper route import/exports are done is to
+ use two Route Targets; call them T1 and T2. If a particular VRF
+ interface attaches to a CE router that is managed by the SP, then
+ that VRF is configured to:
+
+ - import routes that have T1 attached to them, and
+
+ - attach T2 to addresses assigned to each end of its VRF
+ interfaces.
+
+ If a particular VRF interface attaches to the SP's network management
+ system, then that VRF is configured to attach T1 to the address of
+ that system, and to import routes that have T2 attached to them.
+
+
+
+
+
+Rosen & Rekhter Standards Track [Page 36]
+
+RFC 4364 BGP/MPLS IP VPNs February 2006
+
+
+13. Security Considerations
+
+13.1. Data Plane
+
+ By security in the "data plane", we mean protection against the
+ following possibilities:
+
+ - Packets from within a VPN travel to a site outside the VPN, other
+ than in a manner consistent with the policies of the VPN.
+
+ - Packets from outside a VPN enter one of the VPN's sites, other
+ than in a manner consistent with the policies of the VPN.
+
+ Under the following conditions:
+
+ 1. a backbone router does not accept labeled packets over a
+ particular data link, unless it is known that that data link
+ attaches only to trusted systems, or unless it is known that
+ such packets will leave the backbone before the IP header or
+ any labels lower in the stack will be inspected, and
+
+ 2. labeled VPN-IPv4 routes are not accepted from untrusted or
+ unreliable routing peers,
+
+ 3. no successful attacks have been mounted on the control plane,
+
+ the data plane security provided by this architecture is virtually
+ identical to that provided to VPNs by Frame Relay or ATM backbones.
+ If the devices under the control of the SP are properly configured,
+ data will not enter or leave a VPN unless authorized to do so.
+
+ Condition 1 above can be stated more precisely. One should discard a
+ labeled packet received from a particular neighbor unless one of the
+ following two conditions holds:
+
+ - the packet's top label has a label value that the receiving
+ system has distributed to that neighbor, or
+
+ - the packet's top label has a label value that the receiving
+ system has distributed to a system beyond that neighbor (i.e.,
+ when it is known that the path from the system to which the label
+ was distributed to the receiving system may be via that
+ neighbor).
+
+
+
+
+
+
+
+
+Rosen & Rekhter Standards Track [Page 37]
+
+RFC 4364 BGP/MPLS IP VPNs February 2006
+
+
+ Condition 2 above is of most interest in the case of inter-provider
+ VPNs (see Section 10). For inter-provider VPNs constructed according
+ to scheme b) of Section 10, condition 2 is easily checked. (The
+ issue of security when scheme (c) of Section 10 is used is for
+ further study.)
+
+ It is worth noting that the use of MPLS makes it much simpler to
+ provide data plane security than might be possible if one attempted
+ to use some form of IP tunneling in place of the MPLS outer label.
+ It is a simple matter to have one's border routers refuse to accept a
+ labeled packet unless the first of the above conditions applies to
+ it. It is rather more difficult to configure a router to refuse to
+ accept an IP packet if that packet is an IP tunneled packet whose
+ destination address is that of a PE router; certainly, this is not
+ impossible to do, but it has both management and performance
+ implications.
+
+ MPLS-in-IP and MPLS-in-GRE tunneling are specified in
+ [MPLS-in-IP-GRE]. If it is desired to use such tunnels to carry VPN
+ packets, then the security considerations described in Section 8 of
+ that document must be fully understood. Any implementation of
+ BGP/MPLS IP VPNs that allows VPN packets to be tunneled as described
+ in that document MUST contain an implementation of IPsec that can be
+ used as therein described. If the tunnel is not secured by IPsec,
+ then the technique of IP address filtering at the border routers,
+ described in Section 8.2 of that document, is the only means of
+ ensuring that a packet that exits the tunnel at a particular egress
+ PE was actually placed in the tunnel by the proper tunnel head node
+ (i.e., that the packet does not have a spoofed source address).
+ Since border routers frequently filter only source addresses, packet
+ filtering may not be effective unless the egress PE can check the IP
+ source address of any tunneled packet it receives, and compare it to
+ a list of IP addresses that are valid tunnel head addresses. Any
+ implementation that allows MPLS-in-IP and/or MPLS-in-GRE tunneling to
+ be used without IPsec MUST allow the egress PE to validate in this
+ manner the IP source address of any tunneled packet that it receives.
+
+ In the case where a number of CE routers attach to a PE router via a
+ LAN interface, to ensure proper security, one of the following
+ conditions must hold:
+
+ 1. All the CE routers on the LAN belong to the same VPN, or
+
+ 2. A trusted and secured LAN switch divides the LAN into multiple
+ VLANs, with each VLAN containing only systems of a single VPN;
+ in this case, the switch will attach the appropriate VLAN tag
+ to any packet before forwarding it to the PE router.
+
+
+
+
+Rosen & Rekhter Standards Track [Page 38]
+
+RFC 4364 BGP/MPLS IP VPNs February 2006
+
+
+ Cryptographic privacy is not provided by this architecture, nor by
+ Frame Relay or ATM VPNs. These architectures are all compatible with
+ the use of cryptography on a CE-CE basis, if that is desired.
+
+ The use of cryptography on a PE-PE basis is for further study.
+
+13.2. Control Plane
+
+ The data plane security of the previous section depends on the
+ security of the control plane. To ensure security, neither BGP nor
+ LDP connections should be made with untrusted peers. The TCP/IP MD5
+ authentication option [TCP-MD5] should be used with both these
+ protocols. The routing protocol within the SP's network should also
+ be secured in a similar manner.
+
+13.3. Security of P and PE Devices
+
+ If the physical security of these devices is compromised, data plane
+ security may also be compromised.
+
+ The usual steps should be taken to ensure that IP traffic from the
+ public Internet cannot be used to modify the configuration of these
+ devices, or to mount Denial of Service attacks on them.
+
+14. Quality of Service
+
+ Although not the focus of this paper, Quality of Service is a key
+ component of any VPN service. In MPLS/BGP VPNs, existing L3 QoS
+ capabilities can be applied to labeled packets through the use of the
+ "experimental" bits in the shim header [MPLS-ENCAPS], or, where ATM
+ is used as the backbone, through the use of ATM QoS capabilities.
+ The traffic engineering work discussed in [MPLS-RSVP] is also
+ directly applicable to MPLS/BGP VPNs. Traffic engineering could even
+ be used to establish label switched paths with particular QoS
+ characteristics between particular pairs of sites, if that is
+ desirable. Where an MPLS/BGP VPN spans multiple SPs, the
+ architecture described in [PASTE] may be useful. An SP may apply
+ either intserv (Integrated Services) or diffserv (Differentiated
+ Services) capabilities to a particular VPN, as appropriate.
+
+
+
+
+
+
+
+
+
+
+
+
+Rosen & Rekhter Standards Track [Page 39]
+
+RFC 4364 BGP/MPLS IP VPNs February 2006
+
+
+15. Scalability
+
+ We have discussed scalability issues throughout this paper. In this
+ section, we briefly summarize the main characteristics of our model
+ with respect to scalability.
+
+ The Service Provider backbone network consists of (a) PE routers, (b)
+ BGP Route Reflectors, (c) P routers (that are neither PE routers nor
+ Route Reflectors), and, in the case of multi-provider VPNs, (d)
+ ASBRs.
+
+ P routers do not maintain any VPN routes. In order to properly
+ forward VPN traffic, the P routers need only maintain routes to the
+ PE routers and the ASBRs. The use of two levels of labeling is what
+ makes it possible to keep the VPN routes out of the P routers.
+
+ A PE router maintains VPN routes, but only for those VPNs to which it
+ is directly attached.
+
+ Route reflectors can be partitioned among VPNs so that each partition
+ carries routes for only a subset of the VPNs supported by the Service
+ Provider. Thus, no single route reflector is required to maintain
+ routes for all VPNs.
+
+ For inter-provider VPNs, if the ASBRs maintain and distribute VPN-
+ IPv4 routes, then the ASBRs can be partitioned among VPNs in a
+ similar manner, with the result that no single ASBR is required to
+ maintain routes for all the inter-provider VPNs. If multi-hop EBGP
+ is used, then the ASBRs need not maintain and distribute VPN-IPv4
+ routes at all.
+
+ As a result, no single component within the Service Provider network
+ has to maintain all the routes for all the VPNs. So the total
+ capacity of the network to support increasing numbers of VPNs is not
+ limited by the capacity of any individual component.
+
+16. IANA Considerations
+
+ The Internet Assigned Numbers Authority (IANA) has created a new
+ registry for the "Route Distinguisher Type Field" (see Section 4.2).
+ This is a two-byte field. Types 0, 1, and 2 are defined by this
+ document. Additional Route Distinguisher Type Field values with a
+ high-order bit of 0 may be allocated by IANA on a "First Come, First
+ Served" basis [IANA]. Values with a high-order bit of 1 may be
+ allocated by IANA based on "IETF consensus" [IANA].
+
+
+
+
+
+
+Rosen & Rekhter Standards Track [Page 40]
+
+RFC 4364 BGP/MPLS IP VPNs February 2006
+
+
+ This document specifies (see Section 4.3.4) the use of the BGP
+ Address Family Identifier (AFI) value 1, along with the BGP
+ Subsequent Address Family Identifier (SAFI) value 128, to represent
+ the address family "VPN-IPv4 Labeled Addresses", which is defined in
+ this document.
+
+ The use of AFI value 1 for IP is as currently specified in the IANA
+ registry "Address Family Identifier", so IANA need take no action
+ with respect to it.
+
+ The SAFI value 128 was originally specified as "Private Use" in the
+ IANA "Subsequent Address Family Identifier" registry. IANA has
+ changed the SAFI value 128 from "private use" to "MPLS-labeled VPN
+ address".
+
+17. Acknowledgements
+
+ The full list of contributors can be found in Section 18.
+
+ Significant contributions to this work have also been made by Ravi
+ Chandra, Dan Tappan, and Bob Thomas.
+
+ We also wish to thank Shantam Biswas for his review and
+ contributions.
+
+18. Contributors
+
+ Tony Bogovic
+ Telcordia Technologies
+ 445 South Street, Room 1A264B
+ Morristown, NJ 07960
+
+ EMail: tjb@research.telcordia.com
+
+
+ Stephen John Brannon
+ Swisscom AG
+ Postfach 1570
+ CH-8301
+ Glattzentrum (Zuerich), Switzerland
+
+ EMail: stephen.brannon@swisscom.com
+
+
+
+
+
+
+
+
+
+Rosen & Rekhter Standards Track [Page 41]
+
+RFC 4364 BGP/MPLS IP VPNs February 2006
+
+
+ Marco Carugi
+ Nortel Networks S.A.
+ Parc d'activites de Magny-Les Jeunes Bois CHATEAUFORT
+ 78928 YVELINES Cedex 9 - FRANCE
+
+ EMail: marco.carugi@nortelnetworks.com
+
+
+ Christopher J. Chase
+ AT&T
+ 200 Laurel Ave
+ Middletown, NJ 07748
+ USA
+
+ EMail: chase@att.com
+
+
+ Ting Wo Chung
+ Bell Nexxia
+ 181 Bay Street
+ Suite 350
+ Toronto, Ontario
+ M5J2T3
+
+ EMail: ting_wo.chung@bellnexxia.com
+
+
+ Eric Dean
+
+
+ Jeremy De Clercq
+ Alcatel Network Strategy Group
+ Francis Wellesplein 1
+ 2018 Antwerp, Belgium
+
+ EMail: jeremy.de_clercq@alcatel.be
+
+
+ Luyuan Fang
+ AT&T
+ IP Backbone Architecture
+ 200 Laurel Ave.
+ Middletown, NJ 07748
+
+ EMail: luyuanfang@att.com
+
+
+
+
+
+
+Rosen & Rekhter Standards Track [Page 42]
+
+RFC 4364 BGP/MPLS IP VPNs February 2006
+
+
+ Paul Hitchen
+ BT
+ BT Adastral Park
+ Martlesham Heath,
+ Ipswich IP5 3RE
+ UK
+
+ EMail: paul.hitchen@bt.com
+
+
+ Manoj Leelanivas
+ Juniper Networks, Inc.
+ 385 Ravendale Drive
+ Mountain View, CA 94043 USA
+
+ EMail: manoj@juniper.net
+
+
+ Dave Marshall
+ Worldcom
+ 901 International Parkway
+ Richardson, Texas 75081
+
+ EMail: dave.marshall@wcom.com
+
+
+ Luca Martini
+ Cisco Systems, Inc.
+ 9155 East Nichols Avenue, Suite 400
+ Englewood, CO, 80112
+
+ EMail: lmartini@cisco.com
+
+
+ Monique Jeanne Morrow
+ Cisco Systems, Inc.
+ Glatt-com, 2nd floor
+ CH-8301
+ Glattzentrum, Switzerland
+
+ EMail: mmorrow@cisco.com
+
+
+
+
+
+
+
+
+
+
+Rosen & Rekhter Standards Track [Page 43]
+
+RFC 4364 BGP/MPLS IP VPNs February 2006
+
+
+ Ravichander Vaidyanathan
+ Telcordia Technologies
+ 445 South Street, Room 1C258B
+ Morristown, NJ 07960
+
+ EMail: vravi@research.telcordia.com
+
+
+ Adrian Smith
+ BT
+ BT Adastral Park
+ Martlesham Heath,
+ Ipswich IP5 3RE
+ UK
+
+ EMail: adrian.ca.smith@bt.com
+
+
+ Vijay Srinivasan
+ 1200 Bridge Parkway
+ Redwood City, CA 94065
+
+ EMail: vsriniva@cosinecom.com
+
+
+ Alain Vedrenne
+ Equant
+ Heraklion, 1041 route des Dolines, BP347
+ 06906 Sophia Antipolis, Cedex, France
+
+ EMail: Alain.Vedrenne@equant.com
+
+19. Normative References
+
+ [BGP] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
+ (BGP-4)", RFC 4271, January 2006.
+
+ [BGP-MP] Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
+ "Multiprotocol Extensions for BGP-4", RFC 2858,
+ June 2000.
+
+ [BGP-EXTCOMM] Sangli, S., Tappan, D., and Y. Rekhter, "BGP
+ Extended Communities Attribute", RFC 4360, February
+ 2006.
+
+ [MPLS-ARCH] Rosen, E., Viswanathan, A., and R. Callon,
+ "Multiprotocol Label Switching Architecture", RFC
+ 3031, January 2001.
+
+
+
+Rosen & Rekhter Standards Track [Page 44]
+
+RFC 4364 BGP/MPLS IP VPNs February 2006
+
+
+ [MPLS-BGP] Rekhter, Y. and E. Rosen, "Carrying Label
+ Information in BGP-4", RFC 3107, May 2001.
+
+ [MPLS-ENCAPS] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
+ Farinacci, D., Li, T., and A. Conta, "MPLS Label
+ Stack Encoding", RFC 3032, January 2001.
+
+20. Informative References
+
+ [BGP-AS4] Vohra, Q. and E. Chen, "BGP Support for Four-Octet
+ AS Number Space", Work in Progress, March 2004.
+
+ [BGP-ORF] Chen, E. and Y. Rekhter, "Cooperative Route
+ Filtering Capability for BGP-4", Work in Progress,
+ March 2004.
+
+ [BGP-RFSH] Chen, E., "Route Refresh Capability for BGP-4", RFC
+ 2918, September 2000.
+
+ [BGP-RR] Bates, T., Chandra, R., and E. Chen, "BGP Route
+ Reflection - An Alternative to Full Mesh IBGP", RFC
+ 2796, April 2000.
+
+ [IANA] Narten, T. and H. Alvestrand, "Guidelines for
+ Writing an IANA Considerations Section in RFCs",
+ BCP 26, RFC 2434, October 1998.
+
+ [MPLS-ATM] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E.,
+ Swallow, G., Rekhter, Y., and P. Doolan, "MPLS
+ using LDP and ATM VC Switching", RFC 3035, January
+ 2001.
+
+ [MPLS/BGP-IPsec] Rosen, E., De Clercq, J., Paridaens, O., T'Joens,
+ Y., and C. Sargor, "Architecture for the Use of
+ PE-PE IPsec Tunnels in BGP/MPLS IP VPNs", Work in
+ Progress, March 2004.
+
+ [MPLS-FR] Conta, A., Doolan, P., and A. Malis, "Use of Label
+ Switching on Frame Relay Networks Specification",
+ RFC 3034, January 2001.
+
+ [MPLS-in-IP-GRE] Worster, T., Rekhter, Y., and E. Rosen,
+ "Encapsulating MPLS in IP or Generic Routing
+ Encapsulation (GRE)", RFC 4023, March 2005.
+
+ [MPLS-LDP] Andersson, L., Doolan, P., Feldman, N., Fredette,
+ A., and B. Thomas, "LDP Specification", RFC 3036,
+ January 2001.
+
+
+
+Rosen & Rekhter Standards Track [Page 45]
+
+RFC 4364 BGP/MPLS IP VPNs February 2006
+
+
+ [MPLS-RSVP] Awduche, D., Berger, L., Gan, D., Li, T.,
+ Srinivasan, V., and G. Swallow, "RSVP-TE:
+ Extensions to RSVP for LSP Tunnels", RFC 3209,
+ December 2001.
+
+ [OSPFv2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April
+ 1998.
+
+ [PASTE] Li, T. and Y. Rekhter, "A Provider Architecture for
+ Differentiated Services and Traffic Engineering
+ (PASTE)", RFC 2430, October 1998.
+
+ [RIP] Malkin, G., "RIP Version 2", STD 56, RFC 2453,
+ November 1998.
+
+ [OSPF-2547-DNBIT] Rosen, E., Psenak, P., and P. Pillay-Esnault,
+ "Using an LSA Options Bit to Prevent Looping in
+ BGP/MPLS IP VPNs", Work in Progress, March 2004.
+
+ [TCP-MD5] Heffernan, A., "Protection of BGP Sessions via the
+ TCP MD5 Signature Option", RFC 2385, August 1998.
+
+ [VPN-MCAST] Rosen, E., Cai, Y., and J. Wijsnands, "Multicast in
+ MPLS/BGP VPNs", Work in Progress, May 2004.
+
+ [VPN-OSPF] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF
+ as the PE/CE Protocol in BGP/MPLS VPNs", Work in
+ Progress, February 2004.
+
+Authors' Addresses
+
+ Eric C. Rosen
+ Cisco Systems, Inc.
+ 1414 Massachusetts Avenue
+ Boxborough, MA 01719
+
+ EMail: erosen@cisco.com
+
+
+ Yakov Rekhter
+ Juniper Networks
+ 1194 N. Mathilda Avenue
+ Sunnyvale, CA 94089
+
+ EMail: yakov@juniper.net
+
+
+
+
+
+
+Rosen & Rekhter Standards Track [Page 46]
+
+RFC 4364 BGP/MPLS IP VPNs February 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Rosen & Rekhter Standards Track [Page 47]
+
diff --git a/monitor/monitor_backend.go b/monitor/monitor_backend.go
@@ -0,0 +1,22 @@
+package monitor
+
+import (
+ //"log"
+ "github.com/gocql/gocql"
+)
+
+type CassandraContext struct {
+ cconfig *gocql.ClusterConfig
+ session *gocql.Session
+}
+
+func (c *CassandraContext) StartCassandra(kspace string, addrs ...string) (err error) {
+ c.cconfig = gocql.NewCluster(addrs...)
+ c.cconfig.Keyspace = kspace
+ c.session, err = c.cconfig.CreateSession()
+ return
+}
+
+func (c *CassandraContext) StopCassandra() {
+ c.session.Close()
+}
diff --git a/monitor/monitor_backend_test.go b/monitor/monitor_backend_test.go
@@ -0,0 +1,32 @@
+package monitor
+
+import (
+ "testing"
+)
+
+var (
+ conerr error
+)
+
+func TestStartStop(t *testing.T) {
+ c := &CassandraContext{}
+ conerr = c.StartCassandra("bgp_mongol_test", "worf.netsec.colostate.edu")
+ if conerr != nil {
+ t.Logf("could not conect to test cassandra instance at worf.netsec.colostate.edu. not failing test")
+ return
+ }
+ c.StopCassandra()
+}
+
+func TestCreateTable(t *testing.T) {
+ c := &CassandraContext{}
+ conerr = c.StartCassandra("bgp_mongol_test", "worf.netsec.colostate.edu")
+ if conerr != nil {
+ t.Logf("could not conect to test cassandra instance at worf.netsec.colostate.edu. not failing test")
+ return
+ }
+ if err := c.session.Query("CREATE TABLE bmf ( prefix text PRIMARY KEY, dat1 text, dat2 text);").Exec(); err != nil {
+ t.Logf(" create table returned error :%v \n", err)
+ }
+ c.StopCassandra()
+}
diff --git a/mrt/mrt.go b/mrt/mrt.go
@@ -0,0 +1,377 @@
+package mrt
+
+import (
+ "bytes"
+ "encoding/binary"
+ "errors"
+ "fmt"
+ "io"
+ "log"
+ "net"
+ "os"
+ "unicode/utf8"
+ //"runtime"
+)
+
+var logger = log.New(os.Stderr, "go-mrt: ", log.Ldate|log.Llongfile)
+
+type MrtHdr struct {
+ Mrt_timestamp uint32
+ Mrt_type uint16
+ Mrt_subtype uint16
+ Mrt_len uint32
+}
+
+type parsefunc func([]byte) MrtSubTyper
+
+type MrtMsg struct {
+ Hdr MrtHdr
+ BGPMsg []byte
+}
+
+type MrtSubTyper interface {
+ Type() string //almost dummy functionality
+ String() string
+}
+
+type MrtOSPFHdr struct {
+ otype uint16
+ RemoteIP uint32
+ LocalIP uint32
+}
+
+func (m *MrtOSPFHdr) Type() string {
+ return "OSPFHdr"
+}
+
+func (m *MrtOSPFHdr) String() string {
+ remip := make(net.IP, 4)
+ locip := make(net.IP, 4)
+ remip[0] = byte(m.RemoteIP)
+ remip[1] = byte(m.RemoteIP >> 8)
+ remip[2] = byte(m.RemoteIP >> 16)
+ remip[3] = byte(m.RemoteIP >> 24)
+ locip[0] = byte(m.LocalIP)
+ locip[1] = byte(m.LocalIP >> 8)
+ locip[2] = byte(m.LocalIP >> 16)
+ locip[3] = byte(m.LocalIP >> 24)
+ return fmt.Sprintf("OSPF Header. Type [%d] Remote IP [%s] Local IP [%s]", m.otype, remip, locip)
+}
+
+type MrtInfoMsg struct {
+ inftype uint16
+ optmsg string
+}
+
+func (m *MrtInfoMsg) String() string {
+ return fmt.Sprintf("Informational Message. Type [%v] Optstring [%s]", m.inftype, m.optmsg)
+}
+
+func (m *MrtInfoMsg) Type() string {
+ return m.String()
+}
+
+func (m *MrtMsg) PFunc() (ret parsefunc, ok bool) {
+ var subtype = m.Hdr.Mrt_subtype
+ var mtype = m.Hdr.Mrt_type
+ infofunc := func(a []byte) MrtSubTyper {
+ runes := []rune{}
+ infomsg := &MrtInfoMsg{inftype: mtype, optmsg: "No Optional Message"}
+ for len(a) > 0 {
+ r, sz := utf8.DecodeRune(a)
+ if r == utf8.RuneError {
+ logger.Println("failed to decode rune in optional message")
+ return infomsg
+ }
+ a = a[sz:]
+ runes = append(runes, r)
+ }
+ if len(runes) > 0 {
+ infomsg.optmsg = string(runes)
+ }
+ return infomsg
+ }
+
+ ospffunc := func(a []byte) MrtSubTyper {
+ ret := &MrtOSPFHdr{otype: subtype}
+ buf := bytes.NewReader(a)
+ err := binary.Read(buf, binary.BigEndian, &ret.RemoteIP)
+ err = binary.Read(buf, binary.BigEndian, &ret.LocalIP)
+ if err != nil {
+ panic(fmt.Sprintf("error while reading binary OSPF header: %s", err))
+ }
+ return ret
+ }
+
+ bgp4mpscfunc := func(a []byte) MrtSubTyper {
+ ret := &MrtBGP4MPStateChangeHdr{}
+ buf := bytes.NewReader(a)
+ if subtype == BGP4MP_STATE_CHANGE {
+ ret.PeerASN = make([]byte, 2)
+ ret.LocalASN = make([]byte, 2)
+ } else {
+ ret.PeerASN = make([]byte, 4)
+ ret.LocalASN = make([]byte, 4)
+ }
+ err := binary.Read(buf, binary.BigEndian, &ret.PeerASN)
+ if err != nil {
+ panic(fmt.Sprintf("error while reading binary BGP4MP header: %s", err))
+ }
+ binary.Read(buf, binary.BigEndian, &ret.LocalASN)
+ binary.Read(buf, binary.BigEndian, &ret.InterfaceInd)
+ binary.Read(buf, binary.BigEndian, &ret.AddrFamily)
+ if ret.AddrFamily == 1 {
+ ret.PeerIP = make([]byte, 4)
+ ret.LocalIP = make([]byte, 4)
+ } else if ret.AddrFamily == 2 {
+ ret.PeerIP = make([]byte, 16)
+ ret.LocalIP = make([]byte, 16)
+ }
+ binary.Read(buf, binary.BigEndian, &ret.PeerIP)
+ binary.Read(buf, binary.BigEndian, &ret.LocalIP)
+ binary.Read(buf, binary.BigEndian, &ret.OldState)
+ binary.Read(buf, binary.BigEndian, &ret.NewState)
+ return ret
+ }
+
+ bgp4mpmsgfunc := func(a []byte) MrtSubTyper {
+ ret := &MrtBGP4MPMsgHdr{}
+ buf := bytes.NewReader(a)
+ if subtype == BGP4MP_MESSAGE {
+ ret.PeerASN = make([]byte, 2)
+ ret.LocalASN = make([]byte, 2)
+ } else if subtype == BGP4MP_MESSAGE_AS4 {
+ ret.PeerASN = make([]byte, 4)
+ ret.LocalASN = make([]byte, 4)
+ }
+ err := binary.Read(buf, binary.BigEndian, &ret.PeerASN)
+ if err != nil {
+ panic(fmt.Sprintf("error while reading binary BGP4MP header: %s", err))
+ }
+ binary.Read(buf, binary.BigEndian, &ret.LocalASN)
+ binary.Read(buf, binary.BigEndian, &ret.InterfaceInd)
+ //fmt.Printf("ADdr family should be:%v\n", binary.BigEndian.Uint16(a[6:8]))
+ binary.Read(buf, binary.BigEndian, &ret.AddrFamily)
+ if ret.AddrFamily == 1 {
+ ret.PeerIP = make([]byte, 4)
+ ret.LocalIP = make([]byte, 4)
+ } else if ret.AddrFamily == 2 {
+ ret.PeerIP = make([]byte, 16)
+ ret.LocalIP = make([]byte, 16)
+ } else {
+ panic("Address Family in BGP4MP msg func is wrong")
+ }
+ binary.Read(buf, binary.BigEndian, &ret.PeerIP)
+ binary.Read(buf, binary.BigEndian, &ret.LocalIP)
+ return ret
+ }
+
+ ret = nil
+ ok = false
+ switch mtype {
+ case MSG_PROTOCOL_BGP4MP:
+ if subtype == BGP4MP_STATE_CHANGE || subtype == BGP4MP_STATE_CHANGE_AS4 {
+ ret, ok = bgp4mpscfunc, true
+ } else if subtype == BGP4MP_MESSAGE || subtype == BGP4MP_MESSAGE_AS4 ||
+ subtype == BGP4MP_MESSAGE_LOCAL || subtype == BGP4MP_MESSAGE_AS4_LOCAL {
+ ret, ok = bgp4mpmsgfunc, true
+ }
+ case MSG_START, MSG_I_AM_DEAD:
+ if subtype == 0 {
+ ret, ok = infofunc, true
+ } else {
+ logger.Println("Mrt type is Informational but Subtype non-zero")
+ }
+ case MSG_PROTOCOL_OSPF:
+ if subtype == 0 || subtype == 1 {
+ ret, ok = ospffunc, true
+ } else {
+ logger.Println("Mrt type is OSPF but Subtype is neither 0 or 1")
+ }
+ case MSG_NULL, MSG_DIE, MSG_PEER_DOWN, MSG_PROTOCOL_BGP, MSG_PROTOCOL_IDRP, MSG_PROTOCOL_BGP4PLUS, MSG_PROTOCOL_BGP4PLUS1:
+ logger.Println("Deprecated message type")
+ default:
+ logger.Printf("unknown. header [%v]\n", m.Hdr)
+ }
+ return
+}
+
+type MrtBGP4MPStateChangeHdr struct {
+ PeerASN []byte
+ LocalASN []byte
+ InterfaceInd uint16
+ AddrFamily uint16
+ PeerIP []byte
+ LocalIP []byte
+ OldState uint16
+ NewState uint16
+}
+
+func (m *MrtBGP4MPStateChangeHdr) Type() string {
+ return "BGP4MPStateChange"
+}
+
+func (m *MrtBGP4MPStateChangeHdr) String() string {
+ return "BGP4MPStateChange"
+}
+
+type MrtBGP4MPMsgHdr struct {
+ PeerASN []byte
+ LocalASN []byte
+ InterfaceInd uint16
+ AddrFamily uint16
+ PeerIP []byte
+ LocalIP []byte
+}
+
+func (m *MrtBGP4MPMsgHdr) Type() string {
+ return "BGP4MPMsg"
+}
+
+func (m *MrtBGP4MPMsgHdr) String() string {
+ if len(m.PeerIP) < 4 || len(m.LocalIP) < 4 {
+ return "BGP4MPMsg unable to read IPs"
+ }
+ return fmt.Sprintf("LocalIP:%s RemoteIP:%s", net.IPv4(m.PeerIP[0], m.PeerIP[1], m.PeerIP[2], m.PeerIP[3]), net.IPv4(m.LocalIP[0], m.LocalIP[1], m.LocalIP[2], m.LocalIP[3]))
+}
+
+type MrtTableDumpV1Hdr struct {
+ ViewNum uint16
+ SeqNum uint16
+ Prefix []byte
+ PrefixLen uint8
+ Status uint8
+ OrigTime uint32
+ PeerIP []byte
+ PeerAS uint16
+ AttrLen uint16
+}
+
+func (m *MrtTableDumpV1Hdr) Type() string {
+ return "TableDumpV1Hdr"
+}
+
+func (m *MrtTableDumpV1Hdr) String() string {
+ return "TableDumpV1Hdr"
+}
+
+type MrtFile struct {
+ file io.Reader
+ entries uint32
+ off int64
+}
+
+const (
+ MrtHdr_size = 12
+ dump_size = 10000
+)
+
+// mrt-type consts
+const (
+ MSG_NULL = iota // 0 empty msg (deprecated)
+ MSG_START // 1 sender is starting up
+ MSG_DIE // 2 receiver should shut down (deprecated)
+ MSG_I_AM_DEAD // 3 sender is shutting down
+ MSG_PEER_DOWN // 4 sender's peer is down (deprecated)
+ MSG_PROTOCOL_BGP // 5 msg is a BGP packet (deprecated)
+ MSG_PROTOCOL_RIP // 6 msg is a RIP packet
+ MSG_PROTOCOL_IDRP // 7 msg is an IDRP packet (deprecated)
+ MSG_PROTOCOL_RIPNG // 8 msg is a RIPNG packet
+ MSG_PROTOCOL_BGP4PLUS // 9 msg is a BGP4+ packet (deprecated)
+ MSG_PROTOCOL_BGP4PLUS1 // 10 msg is a BGP4+ (draft 01) (deprecated)
+ MSG_PROTOCOL_OSPF // 11 msg is an OSPF packet
+ MSG_TABLE_DUMP // 12 routing table dump
+ MSG_TABLE_DUMP_V2 // 13 routing table dump
+ MSG_PROTOCOL_BGP4MP = 16 // 16 zebras own packet format
+ MSG_PROTOCOL_BGP4MP_ET = 17
+ MSG_PROTOCOL_ISIS = 32 // 32 msg is a ISIS package
+ MSG_PROTOCOL_ISIS_ET = 33
+ MSG_PROTOCOL_OSPFV3 = 48 // 48 msg is a OSPFv3 package
+ MSG_PROTOCOL_OSPFV3_ET = 49
+)
+
+// mrt-subtype consts
+const (
+ BGP4MP_STATE_CHANGE = 0 // state change
+ BGP4MP_MESSAGE = 1 // bgp message
+ BGP4MP_MESSAGE_AS4 = 4 // same as BGP4MP_MESSAGE with 4byte AS
+ BGP4MP_STATE_CHANGE_AS4 = 5
+ BGP4MP_MESSAGE_LOCAL = 6 // same as BGP4MP_MESSAGE but for self
+ BGP4MP_MESSAGE_AS4_LOCAL = 7 // originated updates. Not implemented
+)
+
+const (
+ OSPF_STATE_CHANGE = iota
+ OSPF_LSA_UPDATE
+)
+
+func NewMrtHdr(b []byte) (ret MrtHdr, err error) {
+ buf := bytes.NewReader(b)
+ err = binary.Read(buf, binary.BigEndian, &ret)
+ return
+}
+
+func NewMrtFile(f io.Reader) (ret MrtFile) {
+ ret = MrtFile{f, 0, 0}
+ return
+}
+
+//This function can be passed into a bufio.Scanner.Split() to read buffered
+//mrt msgs
+func SplitMrt(data []byte, atEOF bool) (advance int, token []byte, err error) {
+ if atEOF && len(data) == 0 {
+ return 0, nil, nil
+ }
+ if cap(data) < MrtHdr_size { // read more
+ return 0, nil, nil
+ }
+ //this reads the data and (they are big endian so it handles that)
+ hdr, errh := NewMrtHdr(data[:MrtHdr_size])
+ if errh != nil {
+ return 0, nil, errh
+ }
+ totlen := int(hdr.Mrt_len + MrtHdr_size)
+ if len(data) < totlen { //need to read more
+ return 0, nil, nil
+ }
+ //logger.Printf("scanned mrt with len:%d datalen is :%d", totlen, len(data))
+ return totlen, data[0:totlen], nil
+}
+
+func (f *MrtFile) Read(b []byte) (n int, err error) {
+ //fmt.Printf(" b len:%v cap:%v\n",len(b), cap(b))
+ if cap(b) < MrtHdr_size {
+ err = errors.New("buffer size less than header size")
+ return
+ }
+ n, err = f.file.Read(b[:MrtHdr_size])
+ if err != nil {
+ return
+ }
+ hdr, errh := NewMrtHdr(b[:MrtHdr_size])
+ if errh != nil {
+ err = errors.New(fmt.Sprintf("error in reading header from offset %v : %s", f.off, errh))
+ return
+ }
+ //fmt.Printf("got header at offset:%d ! :%v\n", f.off, hdr)
+ //n = int(hdr.Mrt_len+MrtHdr_size)
+ //f.off = f.off + int64(n)
+ f.entries = f.entries + 1
+ //this will just jump over the msg
+ //noff,errs := f.file.Seek(int64(hdr.Mrt_len), os.SEEK_CUR)
+ if dump_size-(hdr.Mrt_len+MrtHdr_size) <= 0 {
+ err = errors.New(fmt.Sprintf("bgp message of size:%v at offset is too large", hdr.Mrt_len, f.off+MrtHdr_size))
+ return
+ }
+ //fmt.Printf("i will access b[%v:%v] len:%v cap:%v\n",MrtHdr_size, hdr.Mrt_len+MrtHdr_size, len(b), cap(b))
+ nr, err := f.file.Read(b[MrtHdr_size : hdr.Mrt_len+MrtHdr_size])
+ if nr != int(hdr.Mrt_len) {
+ n = n + nr //header + len of read
+ err = errors.New(fmt.Sprintf("error in reading bgp message of size :%v . got :%v bytes.", hdr.Mrt_len, n))
+ return
+ }
+ n = n + nr
+ f.off += int64(n)
+ //fmt.Printf("seeked at offset:%d \n", f.off)
+ return
+}
diff --git a/mrt/mrt_test.go b/mrt/mrt_test.go
@@ -0,0 +1,118 @@
+package mrt
+
+import (
+ "bufio"
+ "bytes"
+ "encoding/binary"
+ "fmt"
+ "net"
+ "os"
+ "testing"
+)
+
+func TestMrtHdr(t *testing.T) {
+ buf := new(bytes.Buffer)
+ var tdate, tlen uint32 = 1, 4
+ var ttype, tsubtype uint16 = 2, 3
+ mrt := &MrtHdr{tdate, ttype, tsubtype, tlen}
+ fmt.Printf("date:%v type:%v subtype:%v len:%v\n", tdate, ttype, tsubtype, tlen)
+ binary.Write(buf, binary.BigEndian, mrt)
+ fmt.Printf("binary mrt: %x\n", buf.Bytes())
+ mhdr, err := NewMrtHdr(buf.Bytes())
+ if err != nil {
+ t.Fatal(err)
+ }
+ fmt.Printf("recreating MrtHdr from binary :%+v \n", mhdr)
+}
+
+func TestMrtPFunc(t *testing.T) {
+ var (
+ tt1, ts1 = uint16(1), uint16(0) //start
+ tt2, ts2 = uint16(3), uint16(1) //i am dead , but wrong subtype
+ tt3, ts3 = uint16(2), uint16(0) //deprecated
+ tt4, ts4 = uint16(11), uint16(0) //ospf state change
+ tbuf = []byte{0, 0, 0, 0, 0, 0, 0, 0}
+ tf parsefunc
+ ok bool
+ )
+ //binbuf := new(bytes.Buffer)
+ mrt1 := &MrtMsg{
+ Hdr: MrtHdr{1, tt1, ts1, 10},
+ BGPMsg: tbuf,
+ }
+ mrt2 := &MrtMsg{
+ Hdr: MrtHdr{1, tt2, ts2, 10},
+ BGPMsg: tbuf,
+ }
+ mrt3 := &MrtMsg{
+ Hdr: MrtHdr{1, tt3, ts3, 10},
+ BGPMsg: tbuf,
+ }
+ mrt4 := &MrtMsg{
+ Hdr: MrtHdr{1, tt4, ts4, 10},
+ BGPMsg: tbuf,
+ }
+ fmt.Println("trying to parse informational message")
+ if tf, ok = mrt1.PFunc(); !ok {
+ t.Fatal("tf should be non nil")
+ }
+ hdr := tf(mrt1.BGPMsg)
+ fmt.Printf("type is :%s\n", hdr.Type())
+ fmt.Println("trying to parse informational message with opt string")
+ mrt1.BGPMsg = []byte{'f', 'o', 'o', ' ', 's', 't', 'r'}
+ mrt1.Hdr.Mrt_type = tt2
+ if tf, ok = mrt1.PFunc(); !ok {
+ t.Fatal("tf should be non nil")
+ }
+ hdr = tf(mrt1.BGPMsg)
+ fmt.Printf("type is :%s\n", hdr.Type())
+ fmt.Println("trying to parse malformed informational message")
+ if tf, ok = mrt2.PFunc(); ok {
+ t.Fatal("this should fail with tf being nil cause subtype is non-0")
+ }
+ fmt.Println("trying to parse deprecated message")
+ if tf, ok = mrt3.PFunc(); ok {
+ t.Fatal("this should fail with tf being nil cause it's deprecated")
+ }
+ fmt.Println("trying to parse OSPF message")
+ //first call to littleendian to come to hostbyteorder and then switch to big
+ binary.BigEndian.PutUint32(mrt4.BGPMsg[:4], binary.LittleEndian.Uint32(net.IPv4(1, 2, 3, 4).To4()))
+ binary.BigEndian.PutUint32(mrt4.BGPMsg[4:], binary.LittleEndian.Uint32(net.IPv4(5, 6, 7, 8).To4()))
+ //binary.Write(binbuf, binary.BigEndian, net.IPv4allsys.To4())
+ //mrt4.BGPMsg = make([]byte,8)
+ //mrt4.BGPMsg = binbuf.Bytes()
+ //copy(mrt4.BGPMsg,binbuf.Bytes())
+ if tf, ok = mrt4.PFunc(); !ok {
+ t.Fatal("this shouldn't fail")
+ }
+ hdr = tf(mrt4.BGPMsg)
+ fmt.Printf("type is :%s .String representation: %s\n", hdr.Type(), hdr)
+}
+
+func TestScan(t *testing.T) {
+ fmt.Println("testing the scanner interface")
+ f, err := os.Open("../tests/mrt3")
+ if err != nil {
+ t.Fatal(err)
+ }
+ mrtscanner := bufio.NewScanner(f)
+ mrtscanner.Split(SplitMrt)
+ count := 0
+ for mrtscanner.Scan() {
+ count++
+ dat := mrtscanner.Bytes()
+ h, _ := NewMrtHdr(dat[:MrtHdr_size]) /* the error has been checked in Read() */
+ if h.Mrt_len == 0 {
+ t.Logf("terminating from 0 mrt len")
+ return
+ }
+ mrtmsg := MrtMsg{Hdr: h, BGPMsg: dat[MrtHdr_size:]}
+ if tf, ok := mrtmsg.PFunc(); ok {
+ tf(mrtmsg.BGPMsg)
+ }
+ }
+ if err := mrtscanner.Err(); err != nil {
+ fmt.Printf("error: %s", err)
+ }
+ fmt.Printf("scanned and parsed: %d entries from bufio\n", count)
+}
diff --git a/tests/mrt1 b/tests/mrt1
Binary files differ.
diff --git a/tests/mrt2 b/tests/mrt2
Binary files differ.
diff --git a/tests/mrt3 b/tests/mrt3
Binary files differ.
