Sign up to receive free email alerts when patent applications with chosen keywords are publishedSIGN UP

Abstract:

A method for registration of multiple entities belonging to a specific
optical network unit (ONU). In one embodiment, the multiple entity
registration method comprises checking by an optical line terminal (OLT)
if a registration request message received from the specific ONU belongs
to a certain grant, and based on the check result, registering an entity
as either a first or as an additional entity of the specific ONU. In
another embodiment, the method comprises checking by an OLT of a reserved
value of a flags field inside a registration request message, and based
on the check result, registering an entity as either a first or as an
additional entity of the specific ONU. The knowledge by an OLT that
multiple entities belong to a specific ONU is used for grant optimization
and packet data flow optimization.

Claims:

1. A method for packet data flow optimization in a passive optical
network (PON) that includes an optical line terminal (OLT) and a
plurality of optical network units (ONUs) of which at least one is a
multiple entity ONU having a bridge, the method comprising the steps of:
a. determining, by the multiple entity ONU, if a packet originates from
the OLT or from an originating user port; b. searching for a destination
address of said packet; c. if said destination address is not found,
transmitting, by the multiple entity ONU, said packet solely to the OLT;
and d. if said destination address is found, transmitting, by the
multiple entity ONU, said packet to a destination selected from the group
consisting of a destination user port of said multiple entity ONU, other
than said originating user port, and the combination of said OLT and all
user ports except said originating user port; whereby the method removes
the need for a source address learning by the ONU when said packet is
received from the OLT

2. The method of claim 1, wherein said step of transmitting said packet
solely to the OLT is followed by the step of transmitting, by the OLT, of
said packet to a user selected from the group of all user ports except
said originating port and a particular user.

3. The method of claim 1, wherein said destination address found in said
step of searching is a broadcast address, and wherein said step of
transmitting said packet includes transmitting said packet to said OLT
and all user ports except said originating user port.

Description:

CROSS REFERENCE TO EXISTING APPLICATIONS

[0001] This is a Divisional of U.S. Ser. No. 12/710,376 filed Feb. 23,
2010, which is a Continuation of U.S. Ser. No. 10/525,745 filed Feb. 28,
2005, now U.S. Pat. No. 7,688,843, which is national phase of
PCT/IL2003/00666 filed Aug. 11, 2003, which claims priority from U.S.
Provisional Application No. 60/410,317 filed Sep. 13, 2002, and from U.S.
Provisional Application No. 60/413,170 filed. Sep. 25, 2002.

FIELD OF THE INVENTION

[0002] The present invention relates generally to data access systems, and
more particularly to methods for operating data access systems for
Ethernet packet traffic over Passive Optical Networks (PONs), the methods
using and taking advantage of the existence of optical network units with
multiple entities.

BACKGROUND OF THE INVENTION

[0003] An Ethernet PON (EPON) is currently using 1 gigabit per second
transport, which is suitable for very high-speed data applications, as
well as for converged system support (telephone, video, etc.). The
unprecedented amount of bandwidth is directed toward, and arriving from a
single entity, the Optical Network Unit (ONU).

[0004]FIG. 1 shows a PON 100 that facilitates the transmission of data
between an Optical Line Terminal (OLT) 102 and a plurality of ONUs. An
ONU may include a single entity, e.g. ONUs 104 (A) and 106 (C), or an
unlimited number of entities, e.g. ONUs 108 (B) and 110 (D). An entity
inside an ONU may be a single user, a bundle of users as for example in a
Multi Dwelling Unit (MDU) application, or a service, such as voice, video
and data in a converged system. An OLT downlink transmission passes
through passive optical splitters 112a-c and reaches all ONUs. An GNU
uplink transmission passes through all the passive optical splitters
located between the respective ONU and the OLT. For example, an uplink
transmission between ONU 106 and OLT 102 passes through passive optical
splitters 112b and 112a. Due to the physical properties of a passive
optical splitter, only the OLT can receive the transmission from the ONU,
while the other ONUs receive attenuated reflections. The uplink
transmission employs time division multiplexing (TDM) to arbitrate
between different entities transmitting at different times.

[0005] The existing IEEE 802.3 specification, which is incorporated herein
by reference, defines a registration process, shown schematically in FIG.
2. The process as defined therein can handle only a single entity per
ONU. An OLT transmits a registration GATE message dedicated for ONUs
wishing to register. Unregistered ONUs respond with a register request
(REGISTER_REQ) message. The REGISTER_REQ message includes a flags field,
which acts as an operation code (opcode), as it determines the operations
requested by this message. Several ONUs might attempt to register
simultaneously. The transmissions might collide in what is marked as a
"contention zone". The OLT continues the process by transmitting a
REGISTER command and a second, regular GATE message. The second GATE
message allows an ONU to answer with a register acknowledge
(REGISTER_ACK) message.

[0006] An access network should enable provisioning, policing and
accounting of each client. In applications where several users connect to
a single switch, the contribution of each of a plurality of different
user sources to the combined traffic cannot be distinguished. In an EPON
application, which follows a request-grant based protocol, the service
provider wishes to configure an OLT to control the quality of service
(QoS) of the uplink traffic per user. The concept of QoS is well known,
and described for example in for Asynchronous Transfer Machine (ATM)
based systems in the ITU G.983.4 specification, which is incorporated
herein by reference. In addition, any independent decisions made by an
ONU that may cause degradation of performance and lead to an unstable
scheduling algorithm, may confuse the OLT, which does not expect such
independent decisions.

[0007] A simple existing solution to the data-handling problem is shown in
FIG. 3a. The figure describes the behavior of a bridgeless ONU having a
plurality of registered entities. The solution involves two processes.
The process shown on the left (steps 300 till 308) describes the actions
taken when a packet is received from an OLT. The process shown on the
right (steps 310 and 312) describes the actions taken when a packet is
received from one of a plurality of user ports. This solution does not
use a bridge, and the traffic direction decision is based on
multiplexing/demultiplexing (mux/demux).

[0008] The left process begins when a packet is received at step 300. In a
comparison step 302, the packet preamble is compared with all the Logical
Link Identifications (LLIDs) registered for this ONU, the LLIDs serving
for path identification. That is, the packet is identified as directed to
one of the user ports, or as "broadcast" i.e. directed to all ports. If a
user port destination LLID is found but the broadcast bit is not set, the
packet is directed to the user port associated with the LLID in step 304.
If a user port destination LLID is found but the broadcast bit is set,
the traffic is directed to all ports except the one that was found
associated with the LLID in step 306. If the LLID is identified in step
302 as a "broadcast" LLID, then the packet is directed to all registered
user ports in step 308. A packet received from any user port is handled
at step 310. The packet is always transmitted to the OLT in step 312.

[0009] A major disadvantage of this solution is the fact that when two
users want to communicate, the traffic has to go up to the OLT and then
be reflected down. This increases the uplink traffic and decreases the
network utilization, as it leads to upstream-downstream traffic
collisions.

[0010] Another simple existing solution to the data-handling problem is
shown in FIG. 3b. The figure describes the behavior of an ONU with a
single registered entity, the ONU having a bridge. The bridge behavior is
compliant with the IEEE 802.1D specification, which is incorporated
herein by reference. This solution also involves two processes. The
process shown on the left (steps 350 to 360) describes the actions taken
by the ONU when a packet is received from an OLT. The process shown on
the right (steps 362 to 370) describes the actions taken by the ONU when
a packet is received from one of a plurality of user ports.

[0011] In the left process, a packet is received from the OLT in step 350.
The packet preamble is compared with the LLID registered for this ONU in
step 352, to check if the packet's destination is the specific ONU. If a
match is found, the process continues with a Source Address (SA) learning
step 354, in which the SA of the packet is learned and stored in a
database as described in section 7.8 of the IEEE 802.1D specification. In
a Destination Address (DA) search step 356, the DA of the packet is
searched by the OLT inside the SA storage database mentioned above. If
the search result is positive, and the DA is found in a database
associated with one of the user ports, the data is transmitted
specifically toward that port in step 360. Otherwise, the packet is
transmitted to all user ports in step 358.

[0012] In the right process, a packet is received from one of the user
ports in step 362. In step 364, the Source Address (SA) of the packet is
learned from a user port and stored according to the IEEE802.1D
specification, as mentioned above. This is followed by a DA search step
366 similar to step 356. If the search result is "negative" (no DA
found), or the address is "broadcast", a command to transmit the packet
to the OLT and to all user ports except the originating one is issued in
step 372. If the search result is "positive" in the sense that the DA is
learned from the OLT, the packet is transmitted only to the OLT in step
370. If the DA is learned from a user port that is not the originating
port, the packet is transmitted toward that port in step 368.

[0013] The major drawbacks of this solution are the lack of ability on the
part of the OLT to control the uplink bandwidth of each user, and the
requirement to learn all OLT source addresses, which requires expensive
memory storage.

[0014] Therefore, it is desirable to provide a segregation of traffic to
several customers or services in an EPON, in which each customer or
service can be handled separately, enabling finer management and
bandwidth control. It is also highly desirable that the OLT control the
ONU scheduling policing, allowing better control to the service provider,
and avoiding the need for the user to configure correctly the queuing
policy.

SUMMARY OF THE INVENTION

[0015] The present invention is of methods for registration of multiple
entities belonging to one ONU, for improved data flow control involving
the multiple entities ONU, and for grant optimization or "coalescence" in
Ethernet passive optical networks involving the multiple entity ONU.

[0016] According to the present invention there is provided, in a PON that
includes an OLT and a plurality of ONUs, a first embodiment of a method
for registration of multiple entities belonging to a specific ONU. The
first embodiment comprises the steps of checking, by the OLT, if a
registration request message received from a specific ONU belongs to a
certain grant, and based on the checking, deciding, by the OLT, to
register an entity associated with the registration request as a first or
as an additional entity of the specific ONU.

[0017] According to one feature in the first embodiment of the method for
registration of multiple entities belonging to a specific ONU, the
certain grant is either a discovery grant or a normal grant. If it is a
normal grant, the step of deciding includes deciding to register the
entity as an additional entity. If it is a discovery grant, the step of
deciding includes deciding to register the entity as a first entity.

[0018] According to yet another feature in the first embodiment, the
method further comprises a step of deleting all previously registered
entities for the specific ONU.

[0019] According to the present invention there is provided, in a PON that
includes an OLT and a plurality of ONUs, a second embodiment of a method
for registration of multiple entities belonging to a specific ONU. The
second embodiment comprises the steps of checking, by the OLT, of a flags
field residing inside a registration request message received from the
specific ONU, and based on the checking, deciding, by the OLT, to
register an entity associated with the registration request as a first or
as an additional entity of the specific ONU. According to one feature in
the second embodiment of the method, the step of checking includes
checking if the flags field marks an additional registration.

[0020] According to the present invention there is provided, in a passive
optical network (PON) that includes an OLT and a plurality of ONUs, a
third embodiment of a method for registration of multiple entities
belonging to a specific ONU. The third embodiment comprises comprising
the steps of providing each entity of the multiple entity ONU with a
separate identifying media access control address, and performing
sequentially a standard registration process for each entity using its
separate identifying media access control address.

[0021] According to the present invention there is provided, in a PON that
includes an OLT and a plurality of ONUs, a method for grant optimization
by the OLT comprising the steps of: handling, by the OLT, of a current
grant to a specific ONU, the current grant having a current grant
content; storing the current grant content in a current grant variable;
checking in a grant list, by the OLT, if an additional grant having an
additional grant content belongs to the specific ONU; and, if the
additional grant is found, coalescing the current grant content and the
additional grant contents, whereby the coalescing removes the need to add
additional optical overhead to the current grant content.

[0022] According to one feature in the grant optimization method of the
present invention, the step of checking includes comparing, by the ONU,
the current grant time of the current grant with the start grant time of
the additional grant, and the step of coalescing includes leaving a laser
ON, thereby not having to turn-OFF and turn-ON again the laser.

[0023] According to the present invention there is provided, in a PON that
includes an OLT and a plurality of ONUs of which at least one is a
multiple entity ONU having a bridge, a method for packet data flow
optimization comprising the steps of: determining, by the ONU, if a
packet originates from the OLT or from an originating user port;
searching for a destination address of the packet; if said destination
address is not found, transmitting the packet solely to the OLT; else, if
the destination address is found, transmitting the packet to a
destination selected from the group consisting of a destination user port
other that the originating user port, and the combination of said OLT and
all user ports except the originating user port, whereby the method
removes the need for a source address learning by the ONU when the packet
is received from the OLT

[0024] According to one feature in the packet data flow optimization
method, the transmitting of the packet solely to the OLT is followed by
the OLT transmitting the packet to either all user ports except the
originating port, or to a particular user.

[0025] According to another feature in the packet data flow optimization
method of the present invention, if the destination address found in the
step of searching is a broadcast address, the packet is transmitted to
the OLT and to all user ports except the originating user port.

BRIEF DESCRIPTION OF THE DRAWINGS

[0026] The invention is herein described, by way of example only, with
reference to the accompanying drawings, wherein:

[0028]FIG. 2 is a flow diagram of discovery process messages as specified
by the IEEE802.3 standardization body;

[0029] FIG. 3 is a flow diagram showing in (a) an existing data handling
method for an ONU having no bridge and having multiple LLIDs, and in (b)
an existing data handling method for a ONU having a bridge and a single
LLID;

[0030] FIG. 4 shows a flow chart of an embodiment of the multiple entity
ONU registration method of the present invention;

[0031] FIG. 5 shows a flow chart of another embodiment of the multiple
entity ONU registration method of the present invention;

[0032] FIG. 6 is a flow chart of a procedure by which an ONU detects the
OLT registration capability;

[0033] FIG. 7 shows a flow chart of a method for grant optimization by an
OLT according to the present invention, in which multiple entities
belonging to one ONU are taken into account;

[0034] FIG. 8 shows a flow diagram of an ONU processing incoming grant
messages, using the method for grant optimization of the present
invention;

[0035] FIG. 9 shows an illustration of an efficient method for data flow
optimization using a multiple entity ONU with a bridge.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0036] The present invention provides, in various embodiments, methods for
registration of multiple entities belonging to one ONU (also referred to
as "multiple entity ONU registration method"), of data flow control or
"data handling" involving the multiple entities ONU, and of grant
optimization or "coalescence". These embodiments are now described in
detail below.

Multiple Entity Registration

[0037] A first embodiment of the multiple entity ONU registration method
of the present invention is to repeat the registration process of FIG. 2
several times, each time with a different Media Access Control (MAC)
Address, which uniquely identifies each entity. The method is simple and
does not require any knowledge from an OLT, which can be standard
compliant, without enhancements. That is, the OLT will regard each entity
as a different physical entity. The OLT can register an unlimited amount
of physical devices, but is not able to discern that different entities
belong to the same single ONU.

[0038] A second embodiment of the multiple entity ONU registration method
of the present invention is shown in FIG. 4. In this embodiment, the ONU
can register an additional entity on top of the existing one(s). While
the process described in FIG. 4 relates to a single additional entity, it
is clear that the process can be repeated several times to add multiple
entities. The ONU uses one of its granting opportunities to transmit a
REGISTER_REQ message with the ONUs own MAC address. The OLT receives this
message in step 400. In step 402, the OLT checks whether the REGISTER_REQ
message was received during a discovery grant opportunity (or simply
"discovery grant"), or during a normal ("non-discovery") grant
opportunity (or simply "normal grant"). If the message was received
during a normal grant ("No"), then the OLT concludes that the ONU is
already registered, and that the ONU wants to add an additional entity.
The registration process of an additional entity for the same ONU by the
OLT, based on the standard process depicted in FIG. 2, thus continues in
step 404. If the REGISTER_REQ message was received during a discovery
grant ("Yes"), then the OLT assumes this is the first entity registered
for this ONU. Consequently, in step 406 the OLT deletes all the entities
previously registered for this ONU, because no other entities should be
registered if this is the first registration. The OLT then continues the
registration process in step 408.

[0039] A third embodiment of the multiple entity ONU registration method
of the present invention is shown in FIG. 5. It is based on using a
reserved value between 4 and 255 of a flags field inside the REGISTER_REQ
message, as explained below. The OLT receives a REGISTER_REQ message from
an ONU in step 500. In step 502, the OLT checks the reserved value of the
flags field, i.e. if the flags field marks an additional registration. If
the reserved value is a new value defined for the additional
registration, typically 5, the OLT concludes that this entity is an
additional entity for the same ONU. Consequently, the OLT completes the
registration process, using the standard flow depicted on FIG. 2, in step
504. If the flags value is 1, i.e. it indicates a first registration
("No"), then in step 506 the OLT deletes all the entities previously
registered for this ONU, because no other entities should be registered
if this is the first registration. The OLT then continues the process of
registration in step 508.

[0040] Table 1 shows a format of a REGISTER_REQ message, as defined by the
IEEE 802.3 specification. The table includes three columns: a field name,
a field length, and a description of the field. The "description" column
of the table describes the meaning of each field. The first row shows a 6
byte long address of an ONU under a "source address" field name. The next
to last row shows a flags field, which is further elaborated in Table 2,
where the specific values are described.

[0041] Table 2 shows in detail several reserved values of the flags field,
which is the 6th field on the packet, as defined in Table 1. Rows 1
and 3 from the top have constant reserved values (0 and 2 respectively)
that cannot be changed. The 5th row from the top in Table 2 is an
"any value" row, which can assume any reserved value between 4 and 255,
more typically 5, and can thus define new functionalities. Defining new
reserved values for additional registrations will enable an OLT to
realize that the registration attempt is for an additional entity of an
existing ONU. Those skilled in the art will realize that there is one
just way to add the functionality by defining one or more reserved
values. However, those reserved values may assume many possible numbers.

[0042] In the second and third embodiments described above, the method of
the present invention advantageously provides OLT operation optimizations
based on the knowledge that several entities belong to a single ONU.
These advantages include:

[0043] 1. Assistance in maintenance, allowing to utilize physical alarm
information of one entity (such as power alarm, temperature alarm, door
open, etc.) as received from other entities.

[0044] 2. Savings in optical overhead penalty, by coalescing successive
grants to the same ONU (see "grant optimization" below). Grant penalties
such as "laser-on", "AGC lock time", "CDR lock time", and "laser-off"
will be paid only once and not per entity, since an ONU will know not to
turn off the laser when a grant to one of its entities starts immediately
after a grant to one of its other entities.

[0045] 3. Multiple MAC addresses are not required, which reduces the cost
required to acquire and maintain the addresses.

[0046] The optimizations are described and discussed in more detail below.

[0047] FIG. 6 is a flow chart of a procedure by which an ONU detects the
OLT registration capability. From a system perspective, it is preferred
to work in the second or third embodiment, but each of these embodiments
require an awareness of the OLT to the fact that all entities are
physically identical. In the procedure shown in FIG. 6, the ONU is
enabled to detect if the OLT is aware to multiple entities registration,
i.e. if the OLT knows how to bundle several entities as belonging to a
single physical entity. In step 600, the ONU receives a command, which
can arrive from a user or a management system, to register an additional
entity. In step 602, having received such a command, the ONU attempts to
register using the second or third registration options, which are the
options that assume OLT awareness for an ONU having multiple entities. A
successful registration leads to step 604, in which the operation is
paused until a new command to register an additional entity arrives, and
then execution returned to step 602. A failure in registration leads to
step 606, where the number of registration attempts is being compared
with a predefined value, e.g. 16. If the number of attempts in still
smaller than the predefined value, the execution returns to step 602.
Otherwise, the operation continues from step 608, where the ONU tries to
register using option 1, in which the OLT doesn't associate the several
entities registered with a single ONU. A failure in the registration will
lead to an additional attempt in step 608. A success will lead to step
610, where operation is paused until a new command to register an
additional entity arrives, and then execution returns to step 608.

[0048] In summary, advantageously and in contrast with existing methods,
the multiple entity ONU registration method of the present invention
includes an enabling step that allows an OLT to realize that a particular
(or "specific") ONU is trying to register one or more additional
entities. In the second embodiment above, this is achieved by the OLT
checking of whether the REGISTER_REQ message was received during a
discovery grant or during a normal grant in step 402. In the third
embodiment above, this is achieved by the OLT checking the value of the
flags field in step 502. The registration method disclosed herein allows
the use of standard defined messages, e.g. messages defined by the IEEE
802.3 specification, but enhances the registration functionality to
support multiple entities inside a single ONU with a single MAC address.

Grant Optimization

[0049] FIG. 7 shows a flow chart of a method for grant optimization by an
OLT according to the present invention, in which multiple entities
belonging to one ONU are taken into account. In step 700, an OLT receives
a list of all grants to be transmitted. In step 702, the OLT starts to
handle a grant for an entity by retrieving an unhandled grant from the
grant list, and storing its content in a current grant variable storage
(or just "current grant variable"). It is understood that this grant (for
this entity) was not handled previously. After handling by the OLT, the
grant is deleted from the list, to avoid multiple handling. In step 704,
before data transmission begins, the transmitted grant length in time
units is combined by the OLT with optical overhead such as laser-on
delay, CDR lock time, AGC lock time and comma synchronization. In step
706, the OLT searches for other grants belonging to this ONU. If other
grants are not found (grant not found or "negative answer"), the OLT adds
in step 708 additional optical overhead, e.g. laser-off delay time for
grant termination. In step 710, the OLT transmits the grant information,
as stored in the current grant variable, to the ONU. In step 711, the OLT
checks the grant list. If the grant list is empty, the execution returns
to step 700. If the grant list is not empty, the execution return to step
702. If one or more additional grants to the same ONU are found in the
grant list (grant found or "positive answer") in step 706, in step 712
the OLT transmits the current grant information, as stored in the current
grant variable, to the ONU. In step 714, an additional grant toward the
same ONU is retrieved from the grant list, meaning the current grant
variable (which has been emptied) is loaded with the additional grant
parameters. The additional grant is deleted from the list to avoid
multiple handling. The execution then returns to step 706. A key
advantage is achieved here by the fact that in the case of a "positive
answer", i.e. if one or more additional grants to the same ONU are found
in step 706, the transmission of the current grant variable is NOT
accompanied by the addition of optical overhead (i.e. step 708 is not
performed). In other words, since step 712 in the multiple entity ONU
case is equivalent to step 710 in the single entity ONU case, a step
similar to step 708 is "saved" and does not exist in the multiple entity
ONU case. Successive grants to different entities of the same ONU are
thus transmitted successively while skipping the optical overhead
addition in-between, a process termed grant coalescence.

[0050] FIG. 8 shows a flow diagram of an ONU processing incoming grant
messages, using the method for grant optimization of the present
invention. The grant messages are stored in a table sorted by grant start
time (not shown). In a monitoring step 800, a monitoring is performed for
the earliest grant start time in the table, meaning the current time is
compared with the start time of the next grant to start. If a match is
found between the current time and the start time of the next grant to
start, the laser is turned-on in step 802, and operation is paused to
wait for optical overhead delays. In step 804, the ONU remains active
until the running grant ends. If the ONU realizes before the end of the
running grant that a new grant has to start immediately, the ONU leaves
the laser ON in step 804 thus saving the turn-off and the new turn-on
steps. This is also referred to as grant coalescence and is a major
advantage in terms of system performance optimization. Otherwise, the
laser is turned off in step 806, and operation is paused to wait for
optical overhead delays. The execution is then repeated starting again
from step 800.

[0051] In summary, advantageously and in contrast with existing methods,
the multiple grant optimization method of the present invention
facilitates an OLT decision to join grants to the same ONU. The OLT
decision step includes the retrieval of an unhandled grant from a grant
list, and the storage of the grant content in a current grant variable.
In, addition, after handling by the OLT, the grant is deleted from the
list, to avoid multiple handling. The resulting grant order is based on
the order of (same) ONU entities, i.e. the grant start time of different
ONU entities is consecutive. That is, no entities other than the
different entities belonging to the same ONU are granted in between. The
method also facilitates grant coalescence, i.e. the key ONU decision to
leave a laser ON (instead of turning it OFF), if the ONU realizes before
the end of the running grant that a new grant has to start immediately.
The grant coalescence eliminates the optical overhead between grants
belonging to different entities in the same ONU. Existing methods do not
use grant coalescence because of the danger of potential loss of optical
overhead when multiple entities are defined.

Data Flow Optimization

[0052] FIG. 9 shows an illustration of an efficient method for data flow
optimization using a multiple entity ONU with a bridge. The use of the
multiple entity ONU with a bridge combines the benefits of a single
entity ONU having a bridge and a multiple entity ONU without a bridge.
The purpose of "bridging" is to define a specific set of rules to improve
traffic utilization. A major innovative aspect here is the combination of
a bridge that is implemented without SA learning from the OLT side.
Without bridging, traffic from one entity to another in the same ONU will
go through the OLT, which causes high delay, payment for uplink
transmitted bandwidth, and inefficient system utilization.

[0053] As with the existing methods described in FIGS. 3a and 3b, the
method described in FIG. 9 includes two processes, shown on the left and
on the right of the figure. The left process (steps 900-906) describes
the actions taken by the ONU when a packet is received from an OLT. The
right process (steps 908-916) describes the actions taken by the ONU when
a packet is received from one of a plurality of user ports. The method
for data flow optimization using a multiple entity ONU with a bridge
essentially encompasses both processes.

[0054] The left process begins when a packet is received from the OLT in
step 900. The packet preamble is compared with all the LLIDs registered
for the specific multiple entity ONU in step 902. If one of the LLIDs
registered with this ONU is found, the packet is directed to the port
associated with the LLID in step 904. If the received LLID is classified
as a "broadcast" LLID (i.e. it has a reserved LLID value destined for all
ONUs), the packet is directed to all registered user ports in step 906.
The major advantage in this process is that it removes the need of a
Source Address learning step (e.g. in comparison with the left process of
FIG. 3b), which reduces the complexity and the memory required from
implementation. The removal of the need for (or avoidance of) the SA
learning step is explained in more detail below.

[0055] The right process begins when a packet is received from any of a
plurality of user ports inside the multiple entity ONU in step 908. This
may also be referred to as an internal "originating" user port of the
ONU. As in the right process of FIG. 3b, the Source Address of the packet
is learned by the multiple entity ONU with a bridge in step 910, as
arriving from the specific sending or originating port, based on the IEEE
802.1D specification. In step 912, the Destination Address of the packet
is searched by the ONU inside the address database, which contains all
the learned addresses. If the DA is found and matches a destination port
different from the sending (originating) port, the packet is transmitted
toward the destination port found in step 914. In other words, the ONU
takes care of the traffic between its ports without the intervention of
the OLT. If no matching DA is found for any port, the packet is
transmitted only to the OLT in step 916. If the DA is classified as
"broadcast" meaning its destination is to all ports, the packet is
transmitted to the OLT and to all user ports, except the sending one, in
step 918. The major advantages here are the ability of the OLT to control
uplink bandwidth for each user port, and the handling of the internal
traffic inside the ONU without the need to burden the uplink traffic, and
without the need for the internal ONU traffic to be handled in the OLT.

[0056] The avoidance of SA learning in the process that includes receiving
a packet from the OLT emerges from step 916. In existing art, if a DA is
not found for any port in the search of step 912, a standard bridge will
have to transmit the packet not only to the OLT, but to all other user
ports of the ONU except the originating port. There are two reasons why a
DA is not found in a search (step 916). The first is that the DA does not
belong to any of the devices (ports) attached to an ONU, and the second
is that the DA belongs to one of the attached devices, but has not been
learned yet. The second reason is the only one that matters. The solution
disclosed herein is based on the fact that the OLT also performs a DA
search. The OLT will transmit the packet either to the correct ONU user
port (when somehow the OLT knows the correct destination) or will feed it
to all user ports in the PON except the originating one. The connectivity
is guaranteed in either case, since when a user port receives the packet
and answers, the SA is learned in step 910. A prior art ONU with a
standard bridge must have the SA learning function for packets arriving
from the OLT, or alternatively it must always reflect traffic from one
user port to another user port. In other words, in prior art an ONU with
a standard bridge must handle internally the traffic when a DA is not
found, and it cannot rely on the OLT, as done in the present invention.
The reason is that in prior art, an ONU looks like a single port to the
OLT bridge. As such, the OLT must assume that if traffic was received
from this ONU, it must not be reflected back when flooded when the DA is
not found. As a result, the prior art ONU must reflect all unknown
traffic, and in order to avoid these reflections, it must learn the OLT
SA, in contrast with the ONU of the present invention, which does not
have to learn the SA.

[0057] All publications mentioned in this specification are herein
incorporated in their entirety by reference into the specification, to
the same extent as if each individual publication was specifically and
individually indicated to be incorporated herein by reference.

[0058] While the invention has been described with respect to a limited
number of embodiments, it will be appreciated that many variations,
modifications and other applications of the invention may be made. What
has been described above is merely illustrative of the application of the
principles of the present invention. Those skilled in the art can
implement other arrangements and methods without departing from the
spirit and scope of the present invention. In addition, citation or
identification of any reference in this application shall not be
construed as an admission that such reference is available as prior art
to the present invention.

Patent applications by Ariel Maislos, Sunnyvale, CA US

Patent applications by Lior Khermosh, Givatayim IL

Patent applications by Onn Haran, San Jose, CA US

Patent applications by PMC SIERRA ISRAEL LTD.

Patent applications in class Broadcast and distribution system

Patent applications in all subclasses Broadcast and distribution system