Note : Les descriptions sont présentées dans la langue officielle dans laquelle elles ont été soumises.
CA 02401051 2002-08-22
WO 01/63847 PCT/iJS00/42094
-1-
Automated Router Port Extension
1. Field of the Invention
The present invention is directed toward the field of data
communication networks. In particular, the invention is directed to a system
and method for providing a high-speed interface between a user and a wide
area network.
2. Description of the Related Art
IO Many computer users have found that there are many advantages to
linking computers together through a local area network ("LAN"). The most
common type of LAN used is the Ethernet. The use of a LAN allows multiple
users, among other things, to share programs, files, data, and to communicate
using methods such as e-mail.
With the growth of the Internet, many computer users have also found that
there are many advantages to having access to the Internet or some other wide
area network ("WAN"). An early option for providing WAN access was the
provision of a separate communication channel to the outside world for each
computer seeking WAN access. Modems and telephone lines are typically used
with this option. When using this method, for example, a computer seeking
Internet access would gain Internet access through an Internet Service
Provider
("ISP") via the computer's dedicated modem and telephone line. The ISP would
complete the Internet connection by providing the computer with access to one
of the ISP's Internet router ports on a shared basis with other users. This
access
method, however, is highly inefficient, slow and expensive, particularly for
computers linked together via a LAN.
To improve upon the earlier access methods, LAN administrators have
provided computers with WAN access through non-dedicated communication
channels so that resources such as modems and telephone lines, could be shared
and, as a result, used more efficiently. To further improve access, the use of
CA 02401051 2002-08-22
WO 01/63847 PCT/US00/42094
-2-
higher speed access media to the ISP, such as the use of DSL lines or fiber
optic
connections, have been proposed. The use of these higher speed access media,
however, could make the cost of access for the users quite expensive. Wireless
interfaces or dial-up modems could be used to reduce costs but these access
means would yield a much slower connection.
Therefore, there remains a need in this art for a high speed, low cost
system for providing WAN access to multiple users. There remains a more
particular need for a high speed, low cost system for providing WAN access
having an interface that is not complex for the user to implement.
SUMMARY OF THE INVENTION
The present invention further improves upon the access methods noted
above and provides a high speed, low cost system and method for providing
access to a wide area network. The present invention provides a system that
utilizes a high speed communication network to provide a user with high speed
access to a WAN access device. The high speed communication network is
capable of providing multiple users or LANs with a high speed data
communication path to a WAN access device via a high speed access medium,
such as a fiber optic network, on a shared basis so that the cost per user for
use
of the high speed data communication path to the WAN access device is reduced.
The system includes an access engine that adds value to the operational
aspects
of bringing up the high speed Internet connection. The access engine provides
an extended muter port at the user's interface to the system thereby
minimizing
interface complexities for the user, the WAN access service provider, and the
carrier that provides the high speed communication network.
The present invention provides many advantages over the presently
known communication systems for providing WAN access. Not all of~these
advantages are simultaneously required to practice the invention as claimed,
and
the following list is merely illustrative of the types of benefits that may be
provided, alone or in combination, by the present invention. These advantages
CA 02401051 2002-08-22
WO 01/63847 PCT/US00/42094
-3-
include: (1) the use of a high speed communication system such as a fiber
optic
network or SONET/SDH network to transmit data between the user equipment
and the WAN access device; (2) connecting multiple users to the WAN access
device thereby reducing the cost per user for the high speed access to the WAN
device; (3) providing a system in which the user does not have to reconfigure
its
equipment in order to send or receive data packets that are transmitted over a
fiber optic or SONET/SDH network; and (4) providing a system in which the
WAN access device does not have to be reconfigured to send data packets that
are
compatible with a user's communication protocol. In accordance with the
present invention a communication system is provided that provides user
equipment with a high speed link to a wide area network. The system includes
a network that has a plurality of network nodes coupled together by one or
more
data communication paths. The system also includes an access device that is
coupled to one of the network nodes and coupled to the user equipment of at
least
one user. The access device is operable to receive an upstream data packet
from
the user equipment, operable to frame the received upstream data packet into a
format compatible for transmission on the ring network, and operable to
forward
the converted upstream data packet onto at least one data communication path
on
the ring network. The access device is also operable to receive a downstream
data packet from at least one data communication path on the ring network,
operable to frame the received downstream data packet into a format compatible
for receipt by the user equipment, and operable to forward the converted
downstream data packet to the user.
In accordance with the present invention a protocol device for providing
user equipment with an interface to a high speed communication link to a wide
area network is provided. The protocol device comprises a virtual channel
agent
that is operable to receive a data packet from the high speed communication
link
and also operable to transmit a data packet to the high speed communication
link.
The protocol device further comprises a LAN agent that is operable to receive
a
data packet from the user equipment and that is also operable to transmit a
data
CA 02401051 2002-08-22
CVO 01/63847 PCT/US00/42094
-4-
packet to the user equipment.
In one embodiment, the virtual channel agent of the protocol device
comprises a virtual channel framer that is operable to frame a data packet in
a
format that is compatible for transmission on the high speed communication
link
and a virtual channel de-framer that is operable to remove a network
encapsulation format from the data packet received from the high speed
communication link.
In another embodiment, the LAN agent of the protocol device comprises
a LAN framer that is operable to frame data packets in a format that is
compatible
for transmission to the user equipment, an encapsulation detector that is
operable
to detect the frame format used by the user equipment to transfer data
packets,
and a LAN filter that is operable to determine whether a received data packet
is
addressed to the protocol device.
In accordance with the present invention, a method for providing user
equipment with an interface to a high speed communication link to a wide area
network is provided. The method comprises the steps of: providing an access
device that is coupled to a network node in a ring network wherein the network
includes a plurality of network nodes coupled together by one or more data
communication paths; coupling the user equipment to the access device;
receiving an upstream data packet from the user equipment with the access
device; encapsulating the received upstream data packet into a format
compatible
for transmission on the network with the access device; and routing the
encapsulated data packet onto at least one data communication paths on the
ring
network for further transmission to a wide area network access device with the
access device.
In one embodiment, the method also includes the steps of: receiving
a downstream data packet from at least one data-communication path on the
network; encapsulating the received downstream data packet into an
encapsulation format that is compatible for receipt by the user equipment; and
forwarding the encapsulated downstream data packet to the user equipment.
CA 02401051 2002-08-22
WO 01/63847 PCT/US00/42094
-5-
BRIE D .S ,RIPTION OF TH . DRAWINC'~
The present invention will become more apparent from the following
description when read in conjunction with the accompanying drawings wherein:
Fig. 1 is a schematic drawing of a communication system that provides
a fiber extended router port;
Fig. 2 is a more detailed schematic drawing of a communication system
that provides multiple LANs with access to a WAN;
Fig. 3 is a schematic drawing of a ring network used in a preferred
embodiment of the invention;
Fig. 4 is an alternate view of a communication system that provides
multiple LANs with access to a WAN;
Fig. 5 is a diagram illustrating multiple Ethernet data framing formats;
Fig. 6 is a schematic drawing of a preferred Protocol engine;
1 S Figs. 7a, 7b, and 7c are schematic illustrations of alternate LAN
configurations that can be used with the present invention;
Fig. 8 is a flow chart illustrating a preferred process of downstream packet
processing; and
Fig. 9 is a schematic drawing of system operation during a transition
period.
DETAII.R D ~ RTPTION OF TH P FFF RFI~ FMROI~TMFNT
System Description
Referring now to the drawings, figure 1 sets forth a schematic drawing of
a preferred embodiment of a communication system 2 according to the present
invention. The communication system 2 provides a user or a user's local area
network 3 ("LAN") with access to the Internet or some other wide area network
("WAN"). In the embodiment shown, a LAN 3 is provided with Internet access
through a fiber optic system 4. The fiber optic system 4 provides a connection
between the user LAI~,T 3 and an Internet access device such as an Internet
CA 02401051 2002-08-22
WO 01/63847 PCT/US00/42094
-6-
backbone router 5 ("BR"). The BR 5 has a number of ports (not shown) with
Internet protocol ("IP") addresses assigned thereto. Internet access is
achieved
through accessing the ports on the BR 5.
The present invention simplifies the access by providing a fiber extended
router port 6. To the LAN 3, an assigned port from the BR 5 is made to appear
to be physically located at the LAN's interface 6 with the fiber optic system
4.
The provision of this fiber extended router port 6 at the LAN's interface,
thereby,
simplifies the interface requirements for devices 7 on the LAN 3 such as a LAN
muter ("LR") 7a or a LAN Host ("Host") 7b. With the present invention, the
LAN devices 7 communicate with the fiber extended router port 6 using their
existing LAN protocol. The LAN devices 7 aren't required to change the format
they use locally on the LAN to exchange data nor do they need additional
programming in order to transmit data packets to or receive data packets from
the
BR 5 even though a portion of the communication path the data must travel
includes fiber optic networks multiplexers and other devices. In addition,
with
the present invention, the interface for the Internet access device 5 is not
made
more complex. The Internet access device 5 will not require modification or
additional programming to accommodate the various data packet formats used on
the various LANs the Internet access device 5 may provides Internet access
for.
The preferred user LAN 3 is an Ethernet LAN but other LAN types such
as token ring, FDDI, etc., could be used. LAN Hosts 7b preferably are personal
computers ("PCs") but optionally could be servers or other computer or
communication equipment. LAN muter 7a preferably comprises computer or
communication hardware that forwards data from or to other computer or
communication equipment on the LAN 3. LAN router 7a optionally could be
coupled to other subnets (not shown) on the user's premises which interconnect
other LAN hosts (not shown).
Figure 2 sets forth a more detailed view of an exemplary communication
system 2 for providing a plurality of user LANs 3 with access to the Internet
or
other WAN via a fiber optic system. The exemplary communication system 2
CA 02401051 2002-08-22
WO 01/63847 PCT/US00/42094
includes a fiber optic system that preferably is arranged in a ring network 10
and
more preferably in a Synchronous Optical Network ("SONET") or SDH ring.
The communication system 2 also includes a plurality of network nodes 12a,12b,
12c, & 12d that are coupled together in the SONET/SDH ring 10, a plurality of
local or user LANs 3a, 3b & 3c that are coupled to the network nodes 12a, 12b
& 12c, respectively, preferably via fiber optic cables 15, and an Internet or
WAN
access device 5 such as an Internet backbone muter ("BR") coupled to network
node 12d.
Figure 3 sets forth a system diagram of a preferred SONET/SDH ring 20
for use in a communication system that practices the present invention. The
SONET/SDH ring 20 includes a plurality of network nodes 22, labeled NO-N3,
coupled in a ring structure by one or more communication paths 24A, 24B. As
shown in FIG. 3, the two paths 24A, 24B transport SONET/SDH data streams
(many packets/cells) in opposite directions about the ring (I.e., east and
west).
The communication paths 24A, 24B are preferably fiber optic connections (in
SONET/SDH), but could, alternatively be electrical paths or even wireless
connections (in other types of ring networks). In the case of a fiber optic
connection, paths 24A, 24B could be implemented on a single fiber 24, on dual
fibers 24A, 24B, or some other combination of connections. Each network node
22 is preferably coupled to two other network nodes 22 in the ring structure
20.
For example, network node NO is coupled to network nodes N1 and N3. The
coupling between the nodes in FIG. 1 is two-way, meaning that each node 22
transmits and receives data (packets/cells) to and from each of the two other
nodes 22 to which it is connected. Each network node 22 includes at least two
transmitter/receiver interfaces, one for each connection to another node 22.
The
network nodes 22 could be many types of well-known network devices, such as
add-drop multiplexers ("ADMs"), switches, routers, cross-connects or other
types
of devices. The devices 22 shown in FIG. 3 are preferably ADMs. An ADM is
a three terminal device having a local add/drop interface, an upstream network
node interface, and a downstream network node interface. These ADMs 22 are
CA 02401051 2002-08-22
VVO 01/63847 PCT/US00/42094
_g_
coupled to local nodes 26, and are used to add packets/cells from the local
nodes
26 to the SONET/SDH data stream, and conversely to drop packets from the
SONET/SDH data stream to the local nodes 26. A system and method for packet
transport in a SONET/SDH ring network and an exemplary ADM is described in
more detail in commonly-assigned United States Patent Application S/N
09/378,844 ("the '844 application), which is incorporated herein by reference.
For more information on SONET/SDH formats, line-speeds, and theory of
operation, see John Bellamy, Digital Telephofzy, 2d Edition (1991), pp. 403-
425.
The network nodes 22 shown in FIG. 3 may be logically connected by a
plurality of virtual paths that coexist on the physical network connections)
24.
Virtual paths are also known as logical paths or "pipes." For example,
although
there is only one physical connection from node NO to node N1 to node N2,
there
may be numerous virtual paths between these nodes, such as one virtual path
from NO to N1, another from NO to N2 and another from N1 to N2. Each virtual
path may include a plurality of virtual channels, wherein each virtual channel
transports packets (or cells) formatted according to the SONET/SDH SPE. The
use of virtual paths in SONET/SDH ring networks is described in more detail in
commonly-assigned United States Patent Application S/N 09/324,244 ("the '244
application"), which also is incorporated herein by reference.
In the exemplary communication system 2 shown in figure 2, the network
nodes 12a, 12b & 12c are access nodes. The network devices that make up
access nodes 12a,12b & 12c each include an access device or access card ("AC")
14. Each access card 14 is operable to transfer data packets between a user's
equipment on a LAN 3 and other nodes 12 on the ring network 10. The access
cards 14 of the present invention may physically reside within a network
device
of the SONET/SDH ring 10 or alternatively may be coupled to a network device.
The network node 12d of the exemplary communication system 2 is an
Internet gateway node and the network device that makes up the gateway node
12d includes a multiplexor device or concentrator card ("CC") 16. The CC 16
CA 02401051 2002-08-22
WO 01/63847 PCT/US00/42094
-9-
functions as a switch that multiplexes data packets transmitted by the access
nodes 12a, 12b & 12c onto a single data transmission channel 18 for further
routing to the intemet access device 5. The CC 16 also functions as a switch
for
forwarding data packets received over the data transmission channel 18 from
the
Internet access device 5 to one or more access nodes 12a, 12b or 12c.
Router ports are also very expensive. Because of the expense and high
bandwidth capability, muter ports have been configured for shared use between
multiple virtual circuits and sub-interfaces. The concentrator card 16
facilitates
the shared use of a muter port and has a two-fold role. The concentrator card
16
merges the data from the various LANs 3 and access cards 14 on the ring
network
into a single pipe for forwarding to the single router port of the BR 5 to
which the
concentrator card 16 is coupled. In merging the data, the concentrator card 16
couples the data to different interfaces within the muter port. The
concentrator
card's 16 second task is to take data from the BR 5, packet by packet, and
forwards the data to the various access nodes 12 on the ring network.
Protocol Engine
Each access card 14 includes at least one protocol engine 30, as shown in
figure 4, for providing a fiber extended router port 6 to a LAN 3. The
protocol
engine 30 provides a permanent address for use by the LAN devices 7 when
transmitting data packets to the WAN. The protocol engine 30 reformats data
packets from the LAN devices 7 and transmits the reformatted data packets over
the ring 10 through the concentrator interface of CC 16 to a sub-interface of
BR
5. The protocol engine 30 also receives data packets from a sub-interface of
BR
5 through the concentrator interface and reformats those data packets to the
format used on the LAN 3. The protocol engine 30 addresses at least three main
architectural issues: encapsulation, maximum transfer unit ("MTLT"), and
address
resolution.
On a user LAN 3, a number of different data formats could be used for
framing the data packets traveling across the user LAN. For example on an
Ethernet LAN, framing formats such as the Ethernet 2, the IEEE802.3, the
CA 02401051 2002-08-22
WO 01/63847 PCT/US00/42094
-10-
IEEE802.3+SNAP, or others could be used, as illustrated in figure 5. The
protocol engine 30 simplifies the interface between an Internet gateway device
and LAN devices 7 by handling the data encapsulation needed to transfer data
between them. The protocol engine 30 makes the interface requirements for an
5 Internet gateway device 5 less complex by framing data packets from the
gateway
device 5 into the data framing format used on the user LAN 3 so that the
gateway
device 5 does not have to perform this function. The protocol engine also
makes
the interface for the LAN devices 7 less complex by performing the data packet
framing and de-framing necessary for sending data over and receiving data from
a SONET/SDH ring 10.
A preferred way in which the protocol engine 30 handles the
encapsulation of data traveling to and from the user LAN 3 is by being liberal
in
what the protocol engine 30 accepts as Ethernet frames and by being
conservative
in how the protocol engine 30 forwards Ethernet frames. For example, the
1 S protocol engine 30 can accept all Ethernet encapsulation types from the
user LAN
3 and only provide one encapsulation type to the user LAN 3.
MTU becomes an issue when data is transferred between different
networks. The maximum data packet size for each network may differ. For
example, Ethernet 2 encapsulation allows for 1500 octets of data packets and
IEEE 802.3 SNAP networks are limited to 1492 octets. The protocol engine 30
is capable of handling messages received from the BR 5 that are too big for
the
destination user LAN 3.
The protocol engine 30 has two options when the MTU of the BR 5
exceeds the MTU of the user LAN 3. Preferably, when a data packet received
from the BR 5 is too large and cannot be encapsulated into a frame for the
user
LAN 3, the protocol engine 30 will fragment the IP datagram to make it conform
to the Ethernet layer framing, I.e., divide the data packet into smaller
chunks that
can be encapsulated into frames for transmission to the user LAN 3.
Optionally,
the protocol engine 30 can make use of the ICMP 'Datagram Too Big' message.
Under this approach, if a data packet is received that is too large, the
protocol
CA 02401051 2002-08-22
WO 01/63847 PCT/US00/42094
-11-
engine 30 discards the entire data packet and returns an ICMP 'Datagram Too
Big' message to the source of the data packet. The protocol engine 30 analyzes
the 'DF' bit ("Don't Fragment") in the data packet header to determine whether
this is the preferred action to take.
Address Resolution is another task that the protocol engine 30 undertakes
to simplify the interface between an Internet gateway device 5 and LAN devices
7. When encapsulating data packets transmitted to the user LAN 3, the protocol
engine 30 encapsulates the data packets in an Ethernet frame having the proper
source & destination MAC addresses. The source MAC address is fixed to the
one associated with the protocol engine 30. The destination MAC address is
dynamically resolved. For unicast data packets, the protocol engine 30
preferably
uses the ARP process.
A preferred implementation of the protocol engine 30 is shown in figure
6. The preferred protocol engine 30 includes a user LAN port 40 for
interfacing
with the user's LAN and a virtual channel port 42a & 42b for interfacing with
the ring network 10 and completing the virtual path between the router 5,
concentrator card 16, and access card 14. The LAN port 40 is the fiber
extended
muter port 6 of the present invention. The preferred LAN port 40 has an
Ethernet
transmit data port connection 40a and an Ethernet receive data port connection
40b. The protocol engine 30 also has a downstream path and an upstream path
for transferring data. In the downstream data path, data flows downstream from
the backbone muter 5 through the ring network 10 through the protocol engine
in the access card 14 to the user LAN 3. In the upstream data path, data flows
from the user LAN 3 through the protocol engine 30 through the ring network 10
25 to the backbone muter 5.
The preferred protocol engine 30 also comprises a Virtual Channel
("VC") agent 44 and an Ethernet Agent 46. These two agents convert data
packets traveling downstream in the SONET/SDH format to the Ethernet data
format used on the LAN. These two agents also convert Ethernet data packets
30 traveling upstream from the LAN to a SONET/SDH data format.
CA 02401051 2002-08-22
WO 01163847 PCT/LJS00/42094
-12-
In particular, the VC Agent 44 is responsible for performing the functions
required to transmit data to and to receive data from a virtual channel. The
preferred VC Agent 44 comprises a VC de-framer 43 and a VC framer 45. The
VC De-framer 43 is responsible for removing the overhead that is added to a
data
S packet that has been framed or encapsulated to travel over a SONET/SDH ring.
The VC Framer 45, on the other hand, is responsible for encapsulating or
adding
overhead to data packets that are going upstream over a SONET/SDH ring.
The preferred Ethernet Agent 46 performs the required functions to
comply with a standard IEEE802.3 Ethernet Port such as preamble
generation/detection, FCS generation/detection, frame length checking, etc.
The
preferred Ethernet Agent 46 comprises a MAC Filter 47, an Encapsulation
Detector 48, and an Ethernet Framer 49. The MAC filter 47 filters Ethernet
messages passing over the user LAN based on the destination MAC address in
each Ethernet packet. The MAC filter 47 only accepts packets destined to the
MAC address associated with the protocol engine 30 and broadcast/multicast
packets. The encapsulation detector 48 detects the encapsulation format used
on
the LAN 3 and instructs the Ethernet framer 49 on which encapsulation format
to use when sending out packets. The Ethernet Framer 49 constructs the
Ethernet
frame surrounding the IP packet to be sent out of the protocol engine 30 onto
the
LAN 3.
The preferred protocol engine 30 also includes a router agent 50. The
router agent 50 performs a limited routing function such as the ARP table
function and IRDP snooping, etc. The preferred protocol engine 30 does not
perform routing table computation When the LAN 3 includes a LAN muter 7a,
the muter agent forwards all packets received by the protocol engine 30 that
are
not directly addressed to a LAN host 7b to the LAN router 7a.
The preferred protocol engine 30 also includes an address resolution
protocol agent 51 ("ARP") and an ARP database 52. The ARP agent 51 initiates
'ARP request' Ethernet broadcast messages for populating the ARP database 52
and responds to Ethernet 'ARP request' broadcast messages with 'ARP replies'
CA 02401051 2002-08-22
WO 01/63847 PCT/US00/42094
-13-
Ethernet messages when asked to perform binding for the IP address associated
with the protocol engine's 30 Ethernet port. The ARP database 52 houses the
Ethernet MAC address to IP address mapping table for devices 7 on the LAN 3.
The preferred protocol engine 30 includes an IRDP ("ICMP Router
Discovery Protocol") agent 53. (ICMP refers to "Internet Control Message
Protocol.") The IRDP Agent snoops the protocol 'ICMP Router Advertisement'
message. When this message is required from the upstream interface 40b, the
IRDP agent 53 is alerted of the availability of a LAN router 7a on the LAN 3,
and
passes this information on to the muter agent 50. When an ICMP Router
Advertisement message is received from the downstream interface 42a (from the
backbone muter 5), the IRDP agent is informed of the IP address assigned to
the
protocol engine 30 by BR 5.
The preferred protocol engine 30 further includes a RIP (Routing
Information Protocol) agent 54 which snoops messages from the upstream
interface 40b. When a RIP message is snooped, the RIP agent 54 is informed of
the availability of a LAN router 7a on the LAN 3, which the RIP agent 54
passes
on to the router agent 50.
The preferred protocol engine 30 also includes protocol muxes 55 and a
protocol demux 56. The protocol mux multiplexes packets from different
protocol agents. The protocol demux 56 demultiplexes packets from the Ethernet
input stream and sends them to the appropriate agents within protocol engine
30.
In particular, ARPs, RIPS & IRDP packets are snooped from the input and copies
are sent to the appropriate agents inside the protocol engine 30.
The operation of the preferred protocol engine 30 will be described next.
The VC port 42 is connected through a virtual path to the concentrator card
16,
and the concentrator card 14d is coupled to the Internet access device or
backbone
muter 5. In the downstream direction, the backbone muter 5 transmits IRDP
messages that are received by the protocol engine 30. Through IRDP messages,
the backbone router 5 advertises the IP address that it has assigned to a
virtual
channel ("VC"). The protocol engine 30 listens to or snoops the IRDP messages
CA 02401051 2002-08-22
WO 01/63847 PCT/CJS00/42094
-14-
for the IP address assigned to its VC and uses that address. The protocol
engine
30 has a uniquely assigned IEEE Ethernet MAC address assigned by the
manufacturer.
Since the protocol engine 30 has both a MAC address and an IP address,
it can function as an Ethernet router port on the LAN 3. To send a message
over
the Internet, a LAN device 7 sends an Ethernet data packet having an IP data
packet embedded therein addressed to the protocol engine 30 using the protocol
engine's MAC address. The protocol engine 30 then frames the data to a format
for transmission over the optical ring network 10 and forwards the IP packet
through its assigned VC to the backbone router 5.
To determine the protocol engine's MAC address, the host 8 can
broadcast an ARP message over the LAN to the LAN's gateway IP address. The
protocol engine, since it occupies the gateway IP address, sends an ARP reply
message with its MAC address. The LAN device 7 remembers the protocol
engine's MAC address for future routing of IP data packets.
Through the use of the present system, the backbone muter 5 does not
need to know the Ethemet addresses of a LAN host 7b to send IP data packets to
it. The backbone muter 5 merely sends data packets to virtual channels. The
protocol engine 30 then forwards the IP data packet sent to its virtual
channel to
the proper recipient LAN host 7b. The protocol engine 30 binds the MAC
addresses on the LAN 3 and the IP addresses that are coming down from the
backbone router 5.
When an IP packet coming downstream from the backbone muter 5 to the
LAN 3 is received by the protocol engine 30, the protocol engine 30 de-frames
the data packet to strip off the overhead from the optical ring network
transmission and frames the data packet as an Ethernet data packet addressed
to
a host's MAC address on the LAN. - Figure 8 illustrates the process the
protocol
engine 30 performs to determine the MAC address to send the data packet to. If
the protocol engine 30 does not know the recipient's MAC address, the protocol
engine 30 issues an ARP request over the LAN 3 for the MAC address of the
CA 02401051 2002-08-22
WO 01/63847 PCT/US00/42094
-15-
recipient host. The proper host 7b replies with its MAC address. That MAC
address is stored in the ARP database. In one implementation, the protocol
engine 30 then frames the IP packet as an Ethernet packet and transmits the
packet to the MAC address associated with the recipient host. In another
implementation, the protocol engine 30 discards the original data packet and
awaits the re-transmission of the data packet before it frames the IP packet
and
transmits it. In cases where no recipient responds to the ARP request, the
protocol engine 30 optionally may send the packet to the LAN router 7a, if one
exists.
To determine the IP protocol address and MAC address of the LAN router
on the user LAN 3, the protocol engine 30 uses the source IP and MAC addresses
in the RIP advertisement message and/or the IRDP advertisement message.
Figure 9 illustrates the process the protocol engine 30 performs if the ARP
database 52 does not reflect the current user LAN 3 subnet topology during
transition periods (such as during a system boot-up). During such a period,
the
protocol engine 30 will send some downstream data packets to the LR 7a that
were intended for hosts 7b on the directly attached subnet. The LR 7a, in
turn,
forwards the data packets to the proper hosts 7b. The transition periods,
however,
will be temporary because all hosts 7b are required to refresh their ARP
tables.
In the downstream direction within the protocol engine 30, the VC agent
44 receives data packets at the VC port 42. The VC de-framer 43 strips off the
overhead that was added for transmission across the virtual channel. The
resulting IP packet is forwarded to the muter agent 50. The router agent 50
forwards packets destined to LAN hosts 7b to the protocol mux 55 and IRDP
messages to the IRDP agent. The protocol mux 55 forwards data packets to the
Ethernet framer 49. The Ethernet framer 49 formats the data packet using the
encapsulation format used on the LAN 3.
In the upstream direction, Ethernet data packets from the LAN 3 are read
by the MAC filter 47. The protocol engine 30 discards data packets other than
IP and ARP coming upstream. If the data packet is addressed to the protocol
CA 02401051 2002-08-22
WO 01/63847 PCT/US00/42094
-16-
engine 30, the data packet is further processed. The MAC filter 47 strips off
the
Ethernet overhead and passes the resultant IP data packet to the VC framer 45
via
the protocol demux 56 and the protocol mux 55. The VC framer 45 frames the
data packet for transmission across the SONET/SDH network 10. Also, in the
upstream direction, the Ethernet agent 46 via the encapsulation detector 48
snoops Ethernet data packets to determine the type of Ethernet encapsulation
used
on the LAN. The Ethernet encapsulation format information is shared with the
Ethernet framer 49 so that the Ethernet framer 49 can properly frame Ethernet
packets in the downstream path.
The protocol engine 30 of the present invention is capable of operation
with a variety of different LAN configurations. For example, the protocol
engine
30 can interface with a LAN router, which in turn interfaces with the LAN, as
shown in figure 7a. Other examples include the use of the protocol engine 30
on
a flat user LAN as shown in figure 7b and the protocol engine 30 interfacing
with
Proxy/NAT box and a mail gateway, the proxy/Nat box in turn interfacing with
the user as shown in figure 7c. The present invention can also be used on
other
LAN configurations not shown.
Having described in detail the preferred embodiments of the present
invention, including preferred modes of operation, it is to be understood that
this
invention and operation could be constructed and carried out with different
elements and steps. The preferred embodiments are presented only by way of
example and are not meant to limit the scope of the present invention, which
is
defined by the following claims.
