-
Multi-layer Traffic Engineering ExperimentalSystem in IP Optical
Network
Daisaku Shimazaki, Eiji Oki and Kohei ShiomotoNTT Network
Service Systems Laboratories, NTT Corp.3-9-11 Midori-cho
Musashino-shi, Tokyo 180-8585 Japan
Email: {shimazaki.daisaku, oki.eiji,
shiomoto.kohei}@lab.ntt.cojp
Abstract-We developed distributed-controlled multi-layertraffic
engineering system. There is no previous works thatreport the
system. Therefore, we can not confirm feasibility andscalability of
the system. In this paper, we report an experimenton our system
consisting of Internet protocol (IP) routers andoptical
cross-connects (OXCs). In this system, control is providedby
generalized multi-protocol label switching (GMPLS) and IPnetwork
topology and IP routes are dynamically re-configuredto suit traffic
characteristics. These functions prevent trafficcongestion as well
as any decrease in link utilization rates. We hadexperiments to
test behavior of the routers and OXCs depend-ing on traffic
characteristics. We cleared that the distributed-controlled
multi-protocol label switching (MPLS)/GMPLS trafficengineering
system was feasible and scalable by the experiments.
I. INTRODUCTION
Broadband access lines bring various services to the IPnetwork.
Some P2P software and video delivery servicesare causing rapid
increases in traffic loads. New broadbandservices may cause
unforeseeable fluctuations in traffic loads.New broadband network
which can carry traffic of theseservices is required. This network
should be manageablebecause it contains many types of
service.MPLS/GMPLS [1] traffic engineering can meet the above
requirement. We can strictly set the route of an
MPLS/GMPLSlabel-switched path (LSP) from source node to
destinationnode and collect information about LSPs, such as
trafficvalues. In an LSP network, we can control the
assignedbandwidth or quality-of-service (QoS) of every LSP
becausethe network operator or network element can acquire all
LSPinformation.
The centralized MPLS/GMPLS network, unfortunately,
hasscalability and robustness problems. The centralized
networkmeans there is one node that can control the network. In
thecentralized network, a specific node has all information of
thenetwork and indicates all nodes. It is difficult that the
specificnode has scalability and robustness.
Therefore, we focused on the distributed MPLS/GMPLSnetwork. Many
studies have examined the distributedMPLS/GMPLS network [2] - [4].
We previously proposed adistributed control mechanism for the
MPLS/GMPLS network[5]. These papers proposed algorithms of
distributed LSPnetwork and investigated the performance of them.
However,there is no confirmation validation report. We must confirm
thebehavior of the distributed mechanism, stability and
processingcapacity.
This paper introduces distributed MPLS/GMPLS net-work experiment
system called as IP optical network. Weconstructed experimental
system and confirmed distributedMPLS/GMPLS network control. This
system can measure
traffic rate and establish and delete optical LSP dependingon
traffic demand.
The rest of the paper is organized as follows. In Sec-tion II,
we introduce a distributed virtual network topology(VNT)
reconfiguration method. In Section III, distributedMPLS/GMPLS
experimental system we constructed is ex-plained. In Section IV, we
describe the experiment that weconfirmed in the system. In Section
V, the conclusion is given.
II. IP OPTICAL NETWORKA. Virtual Network Topology (VNT)A
multi-layer GMPLS network [1] applies the concept of
hierarchical LSPs. In the network, the higher-layer
networkrefers to a lower-layer LSP as a virtual link called
forwardingadjacency (FA). The virtual network consisting ofFAs is
calledthe VNT [6], [7]. This paper considers two layer LSPs,
packetLSP and optical LSP. Figure 1 shows that a lower-layer
opticalLSP is referred to as a virtual link by a higher-layer
packet LSPand the virtual network consisting of optical LSPs is
called theVNT. Packet LSPs, which carry IP packets, are established
onoptical LSPs.
Fig. 1. Virtual Network Topology (VNT)
B. Traffic-driven VNT re-configurationIf the number of packet
LSPs set in an optical LSP is
fixed, the utilization rate of the optical LSP becomes smallwhen
the traffic carried by the packet LSPs becomes small. Ifthere are
many optical LSPs with low utilization rates, networkutilization
decreases, which raises costs. VNT reconfiguration,which consists
of dynamically establishing and deleting opticalLSPs and rerouting
packet LSPs, can reduce the number ofrouter interfaces and
wavelengths. At the same time, VNTreconfiguration can prevent
network congestion.
In the GMPLS architecture, a link-state routing protocol isused
for topology discovery. Each node advertises the linkstate of all
links originating from the node. The residual
1-4244-1206-4/07/$25.00 2007 IEEE
-
resources on each link are part of the link state. The link
stateis flooded throughout the entire network. When a node sets
upan LSP to a destination, it calculates a feasible route for
theLSP by running the constraint-based shortest path first
(CSPF)algorithm. If a feasible route is found, the node initiates
theLSP setup procedure.
In this scheme, each node runs the VNT calculation al-gorithm,
which requires the current virtual network topologyand the traffic
demand of the packet LSPs. The informationon traffic demand of the
packet LSPs must be advertised.The GMPLS link-state routing
protocol [9] is extended toinclude this traffic demand information.
We need to avoidservice disruption when an optical LSP is released.
The packetLSPs must be rerouted before the underlying optical
LSP.To advertise an optical LSP as dormant, the GMPLS
routingprotocol is extended. Once each node receives the notice of
thedormant link state, it reroutes the packet LSPs on the
dormantoptical LSP to non-dormant optical LSPs. After all
packetLSPs are rerouted, the dormant optical LSP is torn down.
Inthis way, the graceful teardown of LSP is implemented in
adistributed manner.
Fig. 2. Traffic driven VNT re-configuration
The VNT design problem has been extensively studied forstatic
traffic demand [10], [11]. The VNT can be designedfor a given
initial traffic demand. As the network grows, thetraffic demand can
significantly differ from the initial demand.Reconfiguration of the
VNT would be required to adapt suchtraffic demand change.
Several methods for VNT reconfiguration have been pro-posed
[12], [13]. Those methods assume that the future trafficdemand is
given. Those methods aimed at the reduction oftopology change in
reconfiguration process. The new VNTis determined from the current
one to adapt the given trafficdemand. The traffic demand is hard to
anticipate accuratelyin real networks. The traffic demand also
fluctuates frequentlyin real networks. Traffic measurement and
reconfiguration ofthe VNT should be orchestrated to cope with
unpredictabletraffic demand. A method for reconfiguration of the
VNTunder dynamic traffic demand change would be required tocope
with unpredictable traffic demand.
The problem of VNT reconfiguration under dynamic trafficchanges
was studied in a recent work [14]. The methoduses an off-line
algorithm for time-variant offered traffic. Itassumes that a set of
traffic matrices at different instants
is known a priori. Another work on VNT under dynamictraffic
changes includes an on-line reconfiguration method[15]. The method
monitors the traffic instead of assuming anyfuture traffic pattern.
Simple adjustments are made to currentVNT to mitigate congestion
and reclaim network resourcefor under-utilized optical LSPs if
possible. The method isbased on centralized control, which collects
the traffic demandmeasurements and heuristically calculates the new
VNT to
suit the latest traffic demand information. The
centralizedcontroller initiates optical LSP setup/teardown
procedure. Aheuristic algorithm is used to calculate the VNT. A new
opticalLSP is established between the end nodes of multi-hop
trafficwith the highest load using the most congested optical LSP
tomitigate the congestion.A distributed VNT reconfiguration
mechanism that can
handle unpredictable traffic demands is studied in [5]. In
thedistributed approach, each node decides whether it
shouldinitiate optical LSP setup/teardown. Unless the
coordinationmechanism is properly implemented, an inconsistent
VNTmight be formed. The proposed method uses a link-state rout-ing
protocol for each node to share the same virtual topologyand the
traffic demand over the each optical LSP, which ismeasured at the
originating node. Each node calculates the newVNT using a simple
heuristic algorithm, compares it with theold one, and initiates
optical LSP setup/teardown if necessary.
C. VNT re-configuration algorithmWe define two types of traffic
value thresholds; TH: con-
gestion threshold, TL: low utilization threshold, for VNT
re-configuration. Traffic loads on the optical LSPs are measuredat
the ingress nodes of the LSPs and VNT reconfiguration isperformed
when traffic loads exceed TH or fall under TL.When traffic
congestion, as determined against TH, occurs,
the packet LSP in the congested optical LSP that has thelargest
traffic value is selected to be moved. Next, the routertries to
establish an optical LSP between ingress and egressnode of the
target packet LSP. If the optical LSP is established,the target
packet LSP is moved to the optical LSP. Thissequence is repeated
until congestion is resolved.The router tries to delete any optical
LSP whose traffic load
is under TL. Of course, before the deletion, all packet LSPsare
moved to other optical LSPs without triggering congestion.This
sequence is also repeated until the link's low utilizationis
resolved.
Fig. 3. VNT re-configuration algorithm
D. Advertisement of traffic loadsAs mentioned above, traffic
information is advertised by
extended open shortest path first (OSPF). Traffic loads
aremeasured at the ingress nodes of packet and optical LSPs.The
utilized bandwidth information is advertised by the OSPFformat
shown in Figure4. The value of sub TLV type is32773 for packet LSPs
and 32774 for optical LSPs. Utilizedbandwidth is given in units of
mega bytes per second in IEEEfloating Point format.
-
0 1 2 301234561890123456189012345618901
Type length
Utilized bandwidth
Fig. 4. OSPF extension for advertisement of bandwidth
utilization
III. EXPERIMENTAL NETWORK
The experimental network system consisted of GMPLSrouters, GMPLS
OXCs, traffic generators, and a VNT viewer.This section describes
each piece of equipment.
A. Multi-layer networkFigure shows the experimental network.
VNT aview - I
Optical 1NTview 4 NT, 77777 ' e wer
W:oXC3 :Traffic Generator
Fig. 5. Traffic-driven VNT reconfiguration experimental
network
In this multi-layer network, Optical LSPs, whose LSP typeis FSC,
are established between GMPLS routers. Packet LSPsare established
via Optical LSPs terminated in GMPLS routers.In this experimental
network, Packet LSPs are representedby MPLS LSPs, which are
terminated in GMPLS routers,the same as Optical LSPs. Therefore,
routers in this networkhandle GMPLS and MPLS entities.
Table shows the software specifications. We used RED-HAT Linux
patched by MPLS-Linux [17], open-source soft-ware, to realize label
switched routing. To forward pack-ets, we must change parameter
net.ipv4.ip forward in the/etc/sysctl.conf file to enable.
No. Item Spec
1 CPU Pentium 4 3.2GHz2 RAM 2GB DDR2-SDRAM 400MHz ECC3 NIC >
1OOBASE-T x 3 (Control plane IF, One or
more GMPLS data plane IF, One or moreMPLS data plane)
Fig. 7. Hardware specifications of PCs for GMPLS router
[Redhat Linux 9 kernel 2.4.20 + MPLS Linux1.172Self-manufactured
software (OSPF-TE,RSVP-TE)
Fig. 8. Software specifications for GMPLS router
Figure 9 shows the hardware and software structure ofthe GMPLS
router PC. GMPLS controller gathers trafficinformation from the
network interface cards by the simplenetwork management protocol
(SNMP).
Os risement
Other nodeH/W
Fig. 6. Hierarchical network
B. Router
We realized GMPLS routers on commercial PCs. Tableshows the
hardware specifications of the PCs. The PCs hadseveral network
interface cards. One interface card is used forthe GMPLS control
plane. The GMPLS control plane interfacesends and receives OSPF
advertisement packets and RSVP-TE signaling packets, which
establish or release LSPs. Otherinterface cards are used to
implement the GMPLS and MPLSdata planes. Each PC had as many data
plane interfaces as thenumber of TE-links.
Fig. 9. PC module structure for GMPLS router
Figure 10 shows the software module structure of theGMPLS
controller.
In this experimental system, we used self-written
GMPLScontroller software. If NetBSD operating system is used forthe
platform of GMPLS PC router, there is some open sourceMPLS
software, such as AYAME [16].C. OXCThe GMPLS OXC consists of
commercial available optical
switches and the GMPLS controller mentioned above (Figure10). We
realized the GMPLS controller by adding the opticalswitch control
function to the controller designed for GMPLSrouters. In contrast,
TRM and CSPF were deleted because thefunctions of gathering traffic
information and route calculationwere not needed.
. Make configuration file for GMPLS controller software.SW-PORT
is related to SW TYPE, IF ID and Label.
. Compare SW TYPE, IF ID and Label in RSVP messageand GMPLS
controller configuration.
. Change the optical switch.
-
Fig. 10. GMPLS Controller module structure
GMPLScoGntLrolntrplplnnsignal - * Q .RSVP TE signaling
GMPLS TE-link SW I/F7_
Optical switch i
D. Traffic generator
TrfGen is the tool that enables to generate traffic from any
to
any and consists of traffic transceiver unit and controller
unit.
Figure 13 shows characteristics of controller unit of
TrfGen.Traffic pattern in IP network is studied in [18] [20]. Wecan
define traffic pattern as any probability model functionfor each
pairs of sender and receiver and program the patternsas a traffic
schedule. Figure 14 shows the preference view oftraffic profile. We
can change the function of packet size andinter-departure time of
traffic pattern as exponential, Paretoand constant distribution.
The packet over MTU size willbe divided and sent. Figure 15 shows
the view of schedulepreference of traffic pattern. The transceiver
unit of TrfGen isbased on I-ITG version 2.4 [21] which is free
software.
Fig. 12. Configuration table of GMPLS controller for OXC
Traffic volume fi(x): data size11t r, |(1 )Constant
(2)Exponentialfi(x) (3)Pareto
-4 4-- im e
.2
3
..... /
TX 2
Fig. 13. Traffic generator system structure
Fig. 14. Preference view of traffic pattern profile
E. VNT ViewerVNT viewer is the tool that enables the network
status to be
visible. Figure 16 shows view of it. It receives IP and
opticallayer traffic engineering information by OSPF and displaysit
as topology. It also gathers route information of LSP fromingress
router. It can display the traffic value graph of LSPs.The traffic
value information is gathered from ingress routerby SNMP. We can
grasp network status in real time from VNTviewer.
IV. VNT RECONFIGURATION EXPERIMENT
A. Feasibility of VNT reconfiguration experiment with
trafficincreaseldecrease scenario
Packet LSPs were established between all routers. OpticalLSPs
were established between Router A - OXC 1 - RouterB (optical LSP 1)
and Router B - OXC 2 - Router C (opticalLSP 2). Packet LSP 1
between Router A and Router B wasestablished via optical LSP 1.
Packet LSP 2 between Router Band Router C was established via
optical LSP 2. Packet LSP3 between Router A and Router C was
established via opticalLSP 1 and 2.
Constant traffic patterns were loaded to packet LSP 1, 2
andfluctuant traffic was loaded to packet LSP 3. TH = 80kbps,TL =
1Okbps. Figure 17 shows VNT reconfiguration wasperformed when
traffic whose pattern was Pareto distributionwith 1.9 shape
parameter was loaded. The parameter e infigure 17 means
moving-average parameter that was applied tomeasured traffic value,
see Equation (1). Rn is the statisticalrate, e is the
moving-average parameter, X, is rate measured
SW-TYPE IF-ID UPSTREAM SW-PORT/LABEL
FSC A_i D.C. X_i (upstream)X_i (downstream)
LSC A_i L X_ij (upstream)(upstream) X-ijL (downstream)
I__ I______ (downstream) I
-
250Theoretical reconfiguration timee=O.1200
7 150
50
00 5 10 15 20 25 30
Time [hour]Fig. 17. VNT reconfiguration experiment with traffic
increase/decreasescenario
Fig. 15. Preference view of traffic pattern schedule
P-layer view(IP topology, MPLS LSP loadMPLS LSP route) graph
_ ..-
_ *sP~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Il
information is advertised by extended OSPF has no
scalabilityproblem in the aspect of OSPF advertisement load.
100000
c 10000
u 1000
100Ct
o ~ 10
C 10 1
0.11 10 100
Number of nodesOptical-layer view ./ >(Fiber topology,
Optical LSP Status viewroute)
Fig. 16. VNT Viewer
the n-th measurement. Equation (1) shows that a small
eemphasizes the past statistical rate.
Rn = eXn + (1 -e)Rn-1 (1)
Figure 17 shows that VNT re-configuration was performedwhen
measured traffic value was over TH and under TLsuccessfully and the
traffic pattern whose shape parameter was1.9 did not need smoothing
with moving average parameter.
B. ScalabilityAs mentioned above, the traffic value information
is ad-
vertised by OSPF. We should investigate OSPF load becauseOSPF
advertisement interval will be short. Figure 18 showsestimated OSPF
load and measured plots. Each plot is averageof three times
measurements. We estimated OSPF load usingOSPF packet format [22],
[9] and 4. Estimation condition;Average nodal degree: 2.2, OSPF
update interval: 2 seconds,packet LSP: established between all
nodes. We also measuredOSPF load in the experimental system. The
measured plotswere almost on the estimated line. Figure 18 shows
that thecontrol plane of 1000 nodes network should have
throughputabout 15Mbps. Therefore, the method that the traffic
value
Fig. 18. Load of OSPF advertisement
We also measured consumed processor power of GMPLSrouter shown
by figure 19. Each plot is average of three timesmeasurements.
Figure 19 shows that there is little correlationbetween gathering
period of traffic value information andaverage CPU utilization
ratio. Therefore, the method that thetraffic value information is
advertised by extended OSPF hasfew scalability problems in the
aspect of OSPF processingload.C. Packet loss experiment caused by
make-before-break
In this experiment, make-before-break was performed byMPLS LSP
rerouting since this should, in theory, preventpacket loss.
Make-before-break means the procedure of rewrit-ing ingress and
egress router tables, see figure 20.We measured packet loss in the
network topology shown in
IV-A. The threshold traffic rates are TH = 100kbps,
1Mbps,10Mbps, TL = 4kbps, 40kbps, 400kbps. Figure 21 showsthe
result. This figure shows that no packet loss occurred indecreasing
traffic rate. By contrast, some packet loss occurredin increasing
traffic rate.We described the reason why packet loss occurs
below.
Packet order reversalProcess power shortage of the
hardwareothers
We first captured egress node interface to check whetherpacket
order reversal occur or not when VNT reconfiguration
e=l
A.ooook~verage rate --- - e=0 1
j ._ T I T
TL- l/
1000
.l 3k. .l
e=l1 oc=l1.9
-
interface.2.5
2
15
1 1
U 05
Router 1 *
Router 2
Router 3 AA A
4Gathering period [sec]
8
Fig. 19. Consumed CPU power for processing traffic value
advertisement
Ingress Egress
RSVP PATH
RSVP RESV
RSVP CONF
(0 Add new label table entry(2 Change label table entry(O Delete
old label table entry
Fig. 20. Make-before-break procedure
occurred. We recognized however packets were not forwardedto
next hop in ingress node during about 1 second.We checked the next
reason. We assumed that the PC router
did not have enough processor power to forward the
packetswithout packet loss. We measured packet loss with
differentialtraffic rate. Figure 21 shows the results. In our
experimentsystem, the packet loss occurred with 100 kbps in
increasingcase. In contract, the router PC can forward the packets
with400 kbps without packet loss in the decrease case. We canassume
that processor power shortage of the hardware wasnot the cause of
packet loss with comparison between bothexperiments.We made
additional investigations and it become clear that
it takes the Linux kernel a significant time to recognize a
new
Threshold TH 1 OOK 1 M 1OMVNT reconfiguration A A Awith traffic
increasing
Threshold TL 4K 40K 400KVNT reconfiguration 0 0with traffic
decreasing
A: Occasional packet loss0: No packet loss in every times* We
tried each test three times.
Fig. 21. Measurement result of packet loss in VNT
reconfiguration withmake-before-break
V. CONCLUSION
In this paper, we developed IP Optical traffic
engineeringtechnologies to address the requirements. We report the
ex-periment of IP optical traffic engineering that IP routers
andOXCs are controlled by GMPLS and IP network topology andIP
routing are dynamically re-configured depending on trafficvalue
increase and decrease. These function achieved preven-tion of
traffic congestion or decrease of link utilization ratio.We also
confirmed the scalability of our distributed networkscontrol system
logically and experimentally. Additionally, itbecame clear that
make-before-break method prevented packetloss.
REFERENCES[1] E. Mannie, "Generalized Multi-Protocol Label
Switching (GMPLS) Ar-
chitecture," IETF RFC, RFC 3945, Oct. 2004.[2] M. Kodialam and
T. V. Lakshman, "Dynamic Routing of Restorable
Bandwidth-Guaranteed Tunnels Using Aggregated Network
ResourceUsage Information," IEEE/ACM Trans. Networking, vol. 11,
no. 3,pp.399-410, Jun. 2003.
[3] S. Butenweg, "Two distributed reactive MPLS traffic
engineering mech-anisms for throughput optimization in best effort
MPLS networks," Proc.of ISCC 2003, vol. 1, pp. 379-384, Jul.
2003.
[4] B. Dekeris and L. Narbutaite, "Traffic control mechanism
within MPLSnetworks," Proc. of ITI 2004, vol. 1, pp. 603-608, Jun.
2004.
[5] K. Shiomoto, E. Oki, W. Imajuku, S. Okamoto, N. Yamanaka,
"Dis-tributed Virtual Network Topology Control Mechanism in
GMPLS-BasedMultiregion Networks," IEEE JSAC, Vol. 21, No. 8, p.p.
1254 - 1262,Oct. 2003.
[6] K. Shiomoto, D. Papadimitriou, J.L. Le Roux, M. Vigoureux,
D. Brun-gard, "Requirements for GMPLS-based multi-region and
multi-layernetworks (MRN/MLN)," IETF draft,
draft-ietf-ccamp-gmpls-mln-reqs-02.txt, Oct. 2006, work in
progress.
[7] J.L. Le Roux, D. Brungard, E. Oki, D. Papadimitriou, K.
Shiomoto,M. Vigoureux, "Evaluation of existing GMPLS Protocols
against MultiLayer and Multi Region Networks (MLN/MRN)," IETF
draft, draft-ietf-ccampgmpls-mln-eval-02.txt, Oct. 2006, work in
progress.
[8] K. Kompella and Y. Rekhter, "Routing Extensions in Support
of General-ized Multi-Protocol Label Switching (GMPLS)," IETF RFC,
RFC 4202,Oct. 2005.
[9] K. Kompella and Y. Rekhter, "OSPF Extensions in Support of
GeneralizedMulti-Protocol Label Switching (GMPLS)," IETF RFC, RFC
4203, Oct.2005.
[10] R. Ramaswami and K. N. Sivarajan, "Design of logical
topologies forwavelength-routed optical networks," IEEE J. Selected
Areas Commun.,vol. 14, pp. 840 - 851, June 1996.
[11] B. Mukherjee, D. Banerjee, S. Ramamurthy, and A. Mukherjee,
"Someprinciples for designing a wide-area WDM optical network,"
IEEE/ACMTrans. Networking, vol. 4, pp. 684 - 696, Oct. 1996.
[12] J.-F. P. Labourdette, G. W. Hart, and A. S. Acampora,
"Logicallyrearrangeable multihop lightwave networks," IEEE Trans.
Commun.,vol.39, pp. 1223 - 1230, Aug. 1991.
[13] D. Banerjee and B. Mukherjee, "Wavelength-routed optical
networks:Linear formulation, resource budgeting tradeoffs, and a
reconfigurationstudy," IEEE/ACM Trans. Networking, vol. 8, pp. 598
- 607, Oct. 2000.
[14] F. Ricciato, S. Salsano, A. Belmonte, and M. Listanti,
"Off-line con-figuration of a MPLS over WDM network under
time-varying offeredtraffic," in Proc. IEEE INFOCOM, vol. 1, June
2002, pp. 57 - 65.
[15] A. Gencata and B. Mukherjee, "Virtual-topology adaptation
for WDMmesh networks under dynamic traffic," in Proc. IEEE INFOCOM,
vol. 1,June 2002, pp. 48 - 56.
[16] http://www.ayame.org/index.php[17]
http://mpls-linux.sourceforge.net/[18] K. Thompson, G.J. Miller, R.
Wilder, "Wide-area Internet traffic patterns
and characteristics," IEEE Network, Vol. 11, Issue 6, pp. 10-23,
Nov.-Dec.1997.
[19] V. Paxson and S. Floyd, "Wide Area Traffic: The Failure of
PoissonModeling," IEEE/ACM Trans. on Networking, pp. 236-244, June
1995.
[20] W. Leland, M. Taqqu, W. Willinger, and D. Wilson, "On the
Self-Similar Nature of Ethernet Traffic (Extended Version),"
IEEE/ACMTrans.on Networking, pp. 1-15, Feb. 1994.
[21] http://www.grid.unina.it/software/ITG/download.php
[22] J. Moy, "OSPF Version 2," IETF RFC, RFC 2328, Apr.
1998.